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This conference 
is undoubtably the most 
valuable event for software 
developers, bar none. 
The coverage is timely, 
the sessions excellent, and 
the speakers mostly a4 
leaders in the field. 


— Ron Goodheart 
Director 
Treasury Services Corporation 
Santa Monica, California 
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ANTI-BIOTICS 


BLOOD LEECHES 


Are You Using The Right Tools ? 


Since the dawn of time, man has distinguished himself by his use of tools. The better the tool user, the more 


successful. Isn't it refreshing to know that times haven't changed? Successful people — and successful companies — still 
distinguish themselves by their knowledge of available tools and their ability to apply the right ones to the job at hand. 


Today, you are bombarded daily with new visual development tools, application frameworks 


“ 


ahh \NDEPEy 
: . RS Dy 
and database connections. Add to this evolving language standards and design methodologies, and 95S ‘a 





choosing your critical development path is a job in itself. : 


= 
Software Development ‘94 is designed to help you do just that. Past attendees 2 
unanimously agree that the 150-course technical program is the best available for teaching you 
everything from programming for 0S/2, Windows, UNIX and Mac, to GUI design and programming 
distributed applications. Courses are hard-hitting, practical and taught by the best in the business. You simply can’t find 
more value for your training dollar. 

Plus, SD “94 is the place to watch the industry evolve at the biggest tools exhibition in the country. Microsoft, 

Borland, Watcom, Symantec and more than 250 other vendors plan their newest product release celebrations around SD, 
so be there to see the latest tools. Learn to use them before your competition does. 


Today, choosing and using the right tool for the job is more than half the battle. Software Development ‘94 
will help you with both. Call us today to find out more. 


MME CONFERENCE & EXHIBITION 
March 14-18, 1993 2 
gg San Jose Convention Center — 
Sf a ae = 
\ = i Call us at = 
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66 A fantastic conference! 
The ONLY show 
developers should 99 
attend. 


— Brian Francis 
Software Engineer 
Harbinger EDI Services 
Atlanta, Georgia 
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have this idea about every time I play 

Wolfenstein. I dream about going 

back to the press conference where the 

386 was unveiled. As a time traveler 

from 1994, I run past the crowds, 

install Wolfenstein on the sole 386 

computer in the world, and start it up. 

The crowd oohs and ahhs as | blow 
away the first guard, doubtlessly dazzled by 
the digitized speech from the sound card I 
installed the night before. 

I turn around and seize the micro- 
phone from the dumbfounded speaker and 
proclaim: “You see this world? With the 
proper tools, good programming, great art- 
work, and competent project management, 
a small group of people can assemble a game 
of this quality that will run on this processor 
perfectly. So, now the challenge is on for 
game developers to surpass this game and 
show the world what can be done!” 


Developers of Today 

But, alas, it is only a dream. The state of 
the art in game development today is still 
the state of the art, when it should be closer 
to the norm. Ever since the first quarter 
fell through the slot of the first Pong 
machine, the industry has been shrouded in 
secrecy. Has the paranoia that enveloped 
the electronic game industry on behalf of 
keeping a competitive edge served the 
industry well? No. 

Do the game developers of today, 
who arguably have the some of the hardest 
jobs in programming, have the best tools at 
their disposal? Do game developers not 
have to worry if the system they're develop- 
ing for will be viable in six months? Are 
the companies making tomorrow’s com- 
puter operating systems consulting game 
companies to make sure their needs are 
met? And lastly, do game programmers, 
who have to port from the arcade to the 
Super Nintendo Entertainment System to 
Sega’s Game Gear to DOS to myriad con- 


soles, portables, PCs, and arcade machines, 
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have the best porting tools? These ques- 
tions are what I base my answer on. 

For every owner of an Atari 7800, for 
every person who buys a cool DOS game 
only to find out that he or she doesn’t have 
610K of conventional memory, for every 
SNES owner who wants to play Sonic the 
Hedgehog II, there’s one more person who 
is either tuned out, turned off, or has spent 
his or her way out of the electronic game 
market. Clearly, the electronic game 
industry isn’t exactly in a state of ruin, but 
issues such as quality control and over-seg- 
mented markets need to be examined. 
That’s where we come in. 

Game Developer is written for devel- 
opers, prospective developers, and interest- 
ed spectators and discusses the issues of 
code, commerce, and creativity. As far as 
code goes, our technical articles will help 
novices figure it out and help the profes- 
sionals do it better. Commerce topics will 
cover the latest and greatest in computer 
games, what went right for a company, 
where it went wrong, and why it doesn’t do 
it anymore. Creativity will focus on the 
artists of the electronic entertainment 
industry from the graphic artists who make 
game images to the musicians who write 
the scores. 


Hey Out There! 

That’s where we stand, take a look at this 
issue and tell us what you think. We've 
tried to cover as much ground as possible as 
far as the range of subject matter and level 
of information. Let us know who you are, 
what you think, and anything else that 
comes to mind. 

You can contact me at (415) 905- 
2349, on Internet at 71154.676@com- 
puserve.com, or you can write to us at 
Game Developer, 600 Harrison St., San 
Francisco, CA 94107. 


Alexander Antoniades 
Associate Editor 
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Motion Works MepiaSuop’ 


Motion Works MediaShop™, is the premiere multimedia James Powell 
authoring environment and companion for Microsoft® Visual Windows Magazine 
Basic™. It allows developers and programmers to create interac- 


ul : I . 
tive titles, presentations and games without having to develop! the preview | saw at the ‘Microsoft JumpStart 


Multimedia RoadShow', the audience was decid- 
edly impressed with Motion Works MediaShop 
and the people who | talked to afterwards were 
eager to get their hands on it!" 


custom code or learn yet another proprietary language. 


MediaShop™ provides you with stand alone Tools that offer a 
complete animation environment, "Hot Spot" Picture and Video 
editing, and Sound Annotation editing. Then you can take your 
creation made with these tools and tie them into Visual Basic™ 
using the MediaShop™ Controls. 


Steve Banfield 
Microsoft Corporation 


"Visual Basic has been very successful and we 
MediaShop™ is a collection of Multimedia Tools and Controls believe that Motion Works is answering the 


that were created by Title Developers themselves and they have needs of people who want to combine Visual 
yet to find any other product that satisfies their creative needs. Basic and Multimedia. " 


Motion Works MepiaASHop™ suggested retail price is $299.00 us 


See how you can enable your multimedia development by calling 1-800-800-8476 
Motion Works USA, 524 Second Street, San Francisco, CA. 94107, Phone (415) 541-9333, Fax:(415) 541-0555 


All rights reserved. Motion Works is a registered trademark, and MediaShop is a trademark of Motion Works Corp. 
All other brand or product names are trademarks or registered trademarks of their respective holders. * Suggested retail price. 
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eff Braun, president of Maxis, 
wants to be your partner. He 
wants to help you become rich, 
and he wants to help you sell 
games. He envisions shelves 
stocked with your work. 
There’s only one small hitch; 
he wants them all to read “A 
SimCity Add-On.” According to Braun, 


high-end console machines are dead 





coming out of the starting gate. “Where 
they have potential is as [V-top 
machines for interactive television,” he 
says. But that’s years in the future. In 
the meantime, he says, “More PCs are 


sold into the home in a month than 
3DO dreams of selling in a year.” Ina 
world where installed base means every- 
thing, Braun sees nothing coming to 
dethrone the PC as the smartest target 
system. Additionally, the dream of part- 
nering with small game developers can- 
not happen without the capabilities of a 
real operating system. As a matter of 
fact, it cannot happen without some 
advanced operating system capabilities 
that are only now becoming available on 
ie F 

Braun wants to open up SimCity to 
other programs. People who play one 
game are likely to play another, and 
Braun wants to give them as many 
chances as possible to interact with 
Maxis products, even when they're play- 
ing another company’s game. Braun 
envisions SimCity as a virtual world in 
which gamers will have their choice of 
myriad recreational and simulation 
diversions. You think people want to be 
SimCops, SimArchitects, or SimCar- 
Racers? SimCity will create the environ- 
ment and economic conditions, you pro- 
vide the specialized functions. That's 
Jeff Braun’s dream, and you can’t do it 


on a console. 


The Path to Interoperability 

Although Braun’s vision is radical for a 
game company, it’s rapidly becoming the 
common wisdom in the business soft- 
ware community, which calls it “docu- 
ment-centered computing” or “compo- 
nent-based development.” In many 
ways, it makes more sense for game soft- 
ware, with its broad-based demograph- 
ics, than for business software that is 


dominated by only three dominant 





applications (word processing, databases, 

and spreadsheets). If Maxis can’t pull it 

off, someone else will. 
There are three steps along the way 
to total interoperability: 

* Static data exchange. Data formats are 
opened up. Maxis has already done 
this with Mallard and Virtus, which 
will allow you to fly and walk, respec- 
tively, through your SimCity. 

* Limited dynamic interface. No console 
has the ability to run multiple 
processes simultaneously, but all the 
popular desktop operating systems 
(with the important exception of 
DOS) have some multiprocessing and 
interprocess communication ability. 
With this level of interface, gamers 
would be able to interact dynamically 
with an active and evolving SimCity, 
but would not be able to, for instance, 
dynamically change the bitmaps used 
in SimCity. 

* Full programmatic interface. This is the 
big enchilada, a situation in which the 
company creating the “server applica- 
tion” (the gaming world) creates two 
entire interfaces for the program, one 
for the gamer and one for the add-on 
programmer. “Client applications” 
(the add-ons) are able to interact with 
the server application, passing data 
and commands back and forth while 
both processes are running. If your 
space-race program drops a Skylab on 
your city, your SimCity window can 
show the burning chunks raining 
down and slamming into the dome of 
your nuclear power plant. (Hmm... 
SimStrategicDefenselnitiative, any- 
one?) 

Obviously, the first step requires 


little more from the game company than 
a disciplined attitude toward data storage 
and some documentation. The second 
step requires a more sophisticated inter- 
process communication facility that’s 
generally provided by the operating sys- 
tem. Traditionally, the performance 
requirements of games have required 
developers to bypass high-level lan- 
guages and operating-system features. 
Now that the average player’s PC is 
based on a 32-bit microprocessor with 
4MB or more of RAM and ample disk 
storage, and game developers are able to 
program in higher-level languages such 
as C++, it is feasible for games to move 
to this second step through the use of 
such technologies as dynamic data 
exchange. 

The third step requires an even 
more sophisticated interprocess capabili- 
ty, whereby data elements in one pro- 
gram can be exposed to modification by 
another program. This is one of the 
goals of so-called distributed object ori- 
entation. There are a number of tech- 
nologies that could be used, but 
Microsoft’s Object Linking and Embed- 
ding (OLE) 2.x is the most likely one. 


The World of OLE 

This is the point where this article veers 
into total speculation. When I asked the 
people at Maxis to name the technology 
they would be using, they rolled their 
eyes and gave me a look I interpreted as 
“we haven’t made up our minds, and 
we're under nondisclosure about the 
things we’re thinking about.” Since I am 
speculating, from now on I'll use as my 
example a theoretical open gaming envi- 
ronment. 


by Larry O’Brien 


Developing a game 


portable across many 
different systems is a 
daunting tf not 
impossible task. With 
Ihe help of high-level 
languages and OLE 
aX, devlopers now 
have a new window 


Of opportunity. 
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Figure 1. A Simple Container Application 


Contain Windows Application - [Contrl 


OLE 2.x is likely to be the domi- 
nant technology used for open gaming 
environments because the gaming 
industry is so sensitive to installed 
bases. Microsoft’s technology is com- 
plex and, according to some, poorly 
implemented. Nonetheless, it’s difficult 
to see how competing technologies 
from IBM, Apple, or Sun are going to 
convince any game developers that they 
represent viable alternatives. OLE 2.x 
and the C++ class libraries needed to 
handle it are Microsoft’s latest strategic 
weapons in the battle for operating-sys- 
tem dominance. 

We had an opportunity to work 
with a beta version of Microsoft Foun- 
dation Classes that supports OLE 2.01. 
This version of MFC, labeled 2.5, 
should be available in an interim release 
of Microsoft’s Visual C++ package by 
the time you read this. The rest of this 
article is based on a beta copy of the 


WITH 


compiler package. Although it is a late 
beta copy, anything could change by 
shipping time. 

Although I’m generally opposed to 
writing about a product that hasn’t 
shipped yet, this is the only class library 
that I’m aware of that supports OLE 2.x, 
and it’s my strong belief that a class 
library is necessary to insulate the pro- 
grammer from as much of OLE’s com- 
plexities as possible. [’ll try to make clear 
which features are part of OLE, which 
are part of MFC, and which are part of 
Visual C++. 

There are four types of OLE pro- 
grams: 
¢ Containers 
¢ Servers 
¢ Automation servers 
¢ Automation clients. 

The naming is unfortunate, as it 
reflects two uses of the word “server.” A 
container holds frames in which servers 


Listing 1. An Example Dispatch Map ; 
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le: 


. 3 


OLE 2x is likely 
(o become the 


dominant technol- 
OOU Used FOr 
Open gaming 


environments. 





are active (if you embed a graph in a 


word-processing document, the word 
processor is the container application, 
and the graphing program is the server), 
while an automation server is program- 
matically driven by an automation client. 
So an open gaming environment would 
be both a container (so new graphic ele- 
ments could be added) and an automa- 
tion server (so, for instance, new AI rou- 
tines could be plugged in at will). A 
gaming add-on would probably be both 
a server (for display) and an automation 


client (for logic). 


Containers and Servers 
Containers and servers are probably what 
you think of when you think of OLE. 
Figure 1 shows a simple container appli- 
cation that contains two embedded serv- 
er frames. One server application is a 
text-manipulation program, the other is 
a simple drawing application. The 
frames of the servers overlap without a 
problem, and the frame of the drawing 
server overlaps the client area of the con- 
tainer and the frame of the other server. 
In this case, a border is drawn 
around the servers; but in an open gam- 


ing environment, this would probably 





not be the case, and the servers would be 

able to use standard Windows drawing 

modes to paint themselves over the 
background. However, servers must be 
rectangular, and hit detection of overlap- 

ping servers is based on a simplistic Z 

ordering (the last embedded object 

receives the command). 

There are a few more aspects of 
containers and servers that are especially 
important to an open gaming environ- 
ment: 

* A container and server can negotiate 
the display size of the embedded serv- 
er. So, servers can be automatically 
placed and scaled within containers 
without excessive code. 

¢ A server receives different Windows 
messages when it is activated in place 
than when it receives the focus as a 
fully opened independent application. 

The really exciting capability of 
OLE 2.x is OLE automation. An 
automation server (remember, that’s dif- 
ferent than a regular OLE server) creates 
one or more of what are called “dispatch 
interfaces.” ‘This is an interface for other 
programmers and is the most exciting 
thing to happen to programming since 
Bjarne put the PP into C. On the other 
hand, like the rest of OLE, it’s Yet 
Another Microsoft Standard, which are 
notorious for being not-as-portable and 
not-as-stable as promised. 

In MFC, classes derived from CCmd- 
Target can place functions in the dis- 
patch interface simply by calling an 
EnableAutomation() member function in 
their constructor via a dispatch map that 
looks almost identical to a standard 
MFC message map. Figure 2 shows the 
hierarchy for CCmdTarget. Listing 1 
shows an example dispatch map. Data 
can be directly exposed, although this is 
bad programming form, since you're 
relying on add-on vendors to validate the 
data before calling your function. When 
they don’t and a crash occurs, it will look 
like your program is at fault. 

There are three categories of func- 
tions that would be exposed through a 
gaming environment’s dispatch table: 





i 2. CCmdTarget Hierarchy 


Microsoft Visual C++ - GAMEDEY.MAK <2> Browse GAMEDEY.BS 


“rn [ccmdtarget: : CCmdTarget () 
cwnd jCCmdTarget: :~CCmdTarget () 
CWinApp jstruct AFX_DISPMAP_ENTRY * CCmdTarget 
CGamedevApp struct AFX_INTERFACEMAP ENTRY * CCmd 
CDocTemplate struct AFX_MSGMAP ENTRY * CCmdTarget 
r CSingleDocTemplate iccndtTarget: : :AssertValid () 
CMultiDocTemplate lorudecrout +: hauintnlecurcr() 
CDocument Jstruct CRuntimeClass CCmdTarget::clas 
L& CcoleDocument struct AFX_DISPMAP CCmdTarget:: 
COleObjectFactory = a 


Ley COleTemplateServer 


re of CCmdTarget 
ColeDataSource g:\msve\mfc\include\afxwin.h (1083) 


Leg na 
COleServerItem: :CItemDataSource References to CCmdTarget 


CDocitem :\msvc\mfc\ include\afxwin. h (56) 
i coleClientItem :\msvc\mfc\ include\afxwin. h (1095) 
coleServeriItem :\msve\mfc\include\afxwin.h (1215) 
ColeDropSource :\msve\mfc\include\afxwin.h (1544) 
CHLsire prakyet } g:\msvc\mfc\include\afxdisp. h (337) 
ColeMessageFilter } g:\msvc\mfc\include\afxdisp. h (397) 


* Informational. Every informative piece Linking to the Future 
of data presented to the user by way If OLE captures the hearts and minds of 
of the graphical user interface should the game development community, it 
also be available to automation clients. would mean sweeping changes in the 
* Programmatic Interface. Every action entertainment marketplace. Large com- 
available to a user through the graphi- panies such as Maxis, Electronic Arts, 
cal user interface should also be avail- and LucasFilm would primarily work on 
able to automation clients. creating worlds that were robust con- 
* Modifications. One of the more tainers and automation servers, while 
interesting possibilities of OLE smaller companies would concentrate on 
automation is add-on automation adding value in the form of servers and 
clients that alter internal behavior of automation clients. Microsoft would 
the automation server. In a gaming have enormous leverage in the battle for 
environment, the obvious use for this the home operating system (surprise, 
would be to alter the playability-real- surprise). 
ism-difficulty trade-offs that every Although Maxis is the first game 
game has. company to embrace this idea, the 
Automation clients use a text-based advantages in terms of time-to-market 
command language to control automa- and saved effort are making an impact 
tion servers. All commands follow the already in the field of business software 
basic form AppName.Document.Verb {Para- development. Compared to business 
meter1 Parameter2 ...}. Microsoft is programs, entertainment programs have 
leading the way by providing automa- shorter lifespans, broader demographics, 
tion clients. The latest versions of Visu- and lower profit margins. All these fac- 


al Basic, Excel, and Word are all tors combine to make OLE an appealing 
automation clients (obviously, Visual embed mate. 

Basic is the most versatile, although the 

latest version of Excel has Visual Basic Larry O’Brien 1s the editor of Game 
for Applications and is only slightly less Developer, Software Development, and 
useful). Al Expert magazines. 
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| SuperDB Functions joo asia 
P enemys Hage t= A_Troopattack 


saesessssss=s= 


*/ 


void A_TroopAttack (mobj_t *actor) 
£ 
int damage 


if ('!sctor->target) 
return 


A_FeceTarget (actor) 
if (P_CheckMeleeRange (actor) ) 
{ 
Gamage = (M_Random()x8+1)*3: 
P_Demagetobj (ector->target. actor. actor. damage) 
return 
} 
f 
/ launch 6 missile 
/ 
P_SpawnMissile (actor, actor->target. MT_TROOPSHOT). 


Reading symbols from /usr/shlib/libsys_s.B.shlib...done 


gdb) run 
/serdvol f /Users/ johnc /DoomRe f /DoomRe f.app/DoomRef’ has changed. rereading syw 


Poberoarn received signal 2. Interrupt 
Ox5807d2c in msqg_send_trap () 


New Gare 
IP HENS a 
two’ G Pieee: P_floor.o |386_obj/P_inter.o 
READ Ties?! maputl.o 1386_obj/P_mobj 
‘a. rade Ame setup.o |386_obj/P_spec.o 
A : P_tick.o 1386_obj/P_user.o 
toot $e mepraw.0 1386_O0b)/R_main.o 
eke 7. Smmem things.o |386_obj/sounds.o 
SOWA gees tut 0 \386_0bj/S_sound.o 
386_obj|/V_video.o I386_obj/WI_stuff_o |386_obj/W_wad.o i386_obj/Z_zone.o 
£4 1386_obj/dutils.o 1366_obj/fpfunc.o -IMedia_s -INeXT_s 


By writing in ANSI C on NeXTStep, Id Software is able to develop and test in a true pro- 
grammer’s environment. Then, using a network, developers are able to send the code to 
a test PC running DOS and recompile what they are working on to run the game on its 
natural environment. 





n an era of where it often takes 
20MB to put in all the advertised 
features, they did it in less than 
four. At a time where soundcard 
compatibility was a big problem, 
they added on Disney Sound 
Source as an afterthought for 
demonstrations. As many larger 
game companies are coming to terms 
with cross-platform development, to 
them it comes naturally. They write 
games that would take larger companies 
30 people or more, and the whole com- 
pany comprises seven people. They are 
the programmers at Id Software, and 
what they are doing could change the 
PC game industry forever. 
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The Making of Doom 


Wolfenstein 3D 

It was actually Id’s previous game, 
Wolfenstein 3D, that earned its acco- 
lades. The premise of Wolfenstein 3D 
was straight out of a B-movie, where 
players battles their way out of a Nazi 
castle. What made Wolfenstein 3D 
stand out was its brilliant use of 
bitmapped images, digitized sounds, and 
blazing speed to give the illusion of a 
three-dimensional world. Id made use of 
a technique known as texture mapping 
that, combined with a raycasting engine 
written in assembly language, allowed 
the three-dimensional graphics to be 
playable on the lowest common denomi- 
nator machine, at the time a 286. 

Perhaps, the most amazing aspect 
of Wolfenstein 3D had to do with its 
distribution. It was shareware. Using a 
time-honored shareware technique, the 
first 10 levels of Wolfenstein 3D were 
free. It was the additional levels that 
were sold directly through the distribu- 
tor, a shareware game company called 
Apogee. This allowed people to copy the 
first part of the game, which was public 
domain, and see how well the game per- 
formed on their machines before they 
bought the whole game. The free teaser 
file spread like a virus until it was all over 
the world, with over 20% of the orders 
for the complete version coming in from 
overseas. 

Here is where Id has potentially 
made it’s biggest impact on the PC game 
industry. By releasing a state-of-the-art 
game through shareware, it was able to 
destroy the old shareware game sales 
record, set by Id’s own Commander 
Keen series, by over five times. By total- 
ing sales of over 100,000 units by the 





end of 1993, Id proved that professional- 
quality games could be successfully mar- 
keted via shareware. To truly compare 
shareware to traditional distribution, six 
months after the release of Wolfenstein, 
Id released a revamped version of 
Wolfenstein called Spear of Destiny. As 
of late 1993, Spear of Destiny and 
Wolfenstein had sold 100,000 copies 
apiece and Wolfenstein sales were still 
going strong, but Spear of Destiny sales 
were slipping as it was being forced off 
of retail shelves by newer games. 
However, it’s not the sales total that 
makes this distribution revolutionary, 
but the profit margin. For example, for 
every game of Spear of Destiny sold, Id 
would get about $8.00, half the total 
return split with the retail distributor 
FormGen. In the case of a Nintendo 
cartridge of Wolfenstein, the return 
would only be about $2.00. But, by using 
a shareware distribution system, Id was 
able to recoup the total price of the game 
minus the actual cost or materials and 
having an operator to take orders. In the 
case of Wolfenstein, the cost of materials 
was less than $5.00, and the complete 
game cost $50. Although they did split 
the profit with Apogee, this gave them a 
profit margin any software company 


would envy. 


The Evolution of Id 

Id Software has come a long way from 
its humble roots in Shreveport, La. It 
was at a company that made monthly 
game disks called Softdisk where the 
majority of the Id development team 
met. John Romero, one of Id’s founders, 
was forwarded some fan letters that were 
sent in and tacked them up on the wall 


in his office. He had never given them a 
second thought until one day, when he 
was reading an article in a game maga- 
zine about a shareware game called Cav- 
erns of Kroz, he noticed a familiar 
address. 

It turned out that Scott Miller, 
president of Apogee, saw one of the 
games Romero and his colleagues ha 
created for Softdisk and wanted it for his 
shareware distribution company. Miller, 
knowing that all mail to Softdisk would 
be opened at the front desk, wrote phony 
fan mail to the programmers under a 
variety of names and always ended the 
letters with “please write me at....” When 
John Romero saw the same address on 
all the fan mail, he realized he didn’t 
have as many fans as he thought. But the 
one real fan he did have would have a 
profound impact on his life. 

Miller knew talent when he saw it, 
and he wanted what was going to be the 
future core of the Id development team 
to work for him. Miller gave Romero 
and his team a $2,000 check, and they 
gave him a paragraph containing a game 
idea that would become the first of the 
Commander Keen trilogy. At this point, 
John Romero, John Carmack, and Adri- 
an Carmack quit their jobs at Softdisk 
and formed Id Software with Apogee 
acting as its distributor. After a brief 
time in Madison, Wis., the Id team 
moved to its current headquarters in 
Mesquite, Texas. 

It is in this corner of suburban Dal- 
las that Id Software has really come into 
its own. Joining the founding members 
of lead programmer John Carmack, pro- 
ject leader John Romero, and graphic 
artist Adrian Carmack, were fellow Soft- 
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disk alums chief operations officer Jay 
Wilbur, creative director Tom Hall, and 
printed graphic artist Kevin Cloud. They 
formed the primary development team 
for Wolfenstein and Spear of Destiny, 
and, on completion of those two pro- 


jects, reaped the rewards. 


The Id Domain 


Id’s main working environment is a 
series of PCs networked together, some 
of which run DOS. However, when it 
comes to programming, NeXTStep is 
the team’s weapon of choice. John Car- 
mack has never regretted trudging 
through the snow in Madison to buy a 
NeXT cube. The level editor that 
Romero made for Doom took five 
human-months to make, but would have 
taken much longer on any other operat- 
ing system. 

The Super Nintendo Entertain- 
ment System (SNES) version of 
Wolfenstein was developed mostly on 
the NeXT machine, using an Apple 
IIGS to compile and retarget the ANSI 
C code. For future SNES development, 
Id had planned to retarget the Free Soft- 
ware Foundation Assembler and GNU 
C compiler to generate 65816 code on 
the NeXT machine, using a ROM emu- 
lator card to upload the code compiled in 
NeXTStep 486 directly to the Nintendo 
SNES. 

Figure 1 shows DoomED, a good 
example of what Id can do in 
NeXTStep. It has the functionality of a 
simple CAD program and allows level 
designers to concentrate on level design 
instead of programming. From 
DoomED, the level designer can place 
monsters and objects (the different col- 
ored blocks on the screen), but, more 
importantly, can manipulate the walls, 
ceilings, and floors of the game environ- 
ment. The editor allows bitmap combi- 
nation from a group created by the 
graphic artists, so the level editor can 
improvise without having to draw new 
bitmaps. 

Although it has often been theo- 
rized that Id uses a lot of assembly lan- 
guage in its development, the main lan- 


guage used is ANSI C. “Assembly lan- 
guage is almost dead,” declares Carmack. 
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“Doom has only two assembler routines: 
one to vertically stretch a column and 
the other to horizontally texture-map a 
row. Everything else is in C.” 

If all of Doom was written in 
assembler and the programmer could 
manage the overhead correctly, Carmack 
theorizes it would only make the game 
15% faster. And, although the main 
raycasting trace in Wolfenstein was 
written in assembly language, Carmack 
says he could write Wolfenstein faster 
in C because of today’s better algorithm 
technology. 

Writing in ANSI C eases the strain 
of porting to other operating systems 
and recompiling the code on DOS, and 
NeXTStep helps clean out bugs during 
the development process. Carmack feels 
he could get Doom up and running in a 
window on a Macintosh over a weekend, 
but Id won’t write the port itself. Id is 
willing to work with advocates of various 
operating systems, and talk of Macin- 


tosh, OS/2, and UNIX versions of 


Doom were discussed as possibilities. 


The Core of Id 
The two people at the core of the Id 


development team are the biggest fans of 
Id games and their harshest critics. Lead 
programmer John Carmack is clearly the 
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main reason behind the technical superi- 
ority of Id’s games. Talking to him about 
the games he’s worked on is almost anti- 
climactic because he always emphasizes 
how much better he could make them 
today. When the contractor Id hired to 
do the network drivers for Doom didn’t 
come through, Carmack matter-of-factly 
wrote a network driver and had it up and 
running the next day. 

In contrast to Carmack’s eternal 
pessimism regarding his past creations, 
project specialist John Romero is the 
biggest fan of Id’s games that you could 
ever hope to meet. His enthusiasm is 
infectious as he plays the latest beta 
making his own sound effects with his 
mouth to compensate for the game 
sound effects that haven’t been added in 
yet. It is this mix of diehard programmer 
who plays games and diehard gamer who 
programs that ultimately makes Id’s 
games as good as they are. 

True to form, John Carmack was 
already displeased with Wolfenstein by 
the time it was released to the public. 
His game engine had been completed in 
the first month of the six-month devel- 
opment cycle and, by the time the first 
copy of Wolfenstein was buzzing across 
the modems of America, he knew he 


could do better. While the rest of the Id 


Figure 1. DoomED—Using CAD to Build Hell 
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development team was hard at work 
completing Wolfenstein, Carmack was 
writing the game engine that would 
later be licensed to a company called 
Raven for the game that was to become 
Shadowcaster. 

This game engine featured more 
than a one-point perspective and allowed 
objects to be taller than the player. It was 
around advances made in the Raven 
engine that the new game (tentatively 
titled “Green and Pissed”) was to be 
built. But in the making of what was to 
become Doom, Id Software severed its 
relationships with two of the parties that 
had been around since its beginning. 

In the initial development of Doom, 
a determination was made as to what 
direction Id’s games should take. This 
decision resulted in founding member 
Tom Hall leaving Id Software. Carmack 
and Romero felt that Hall’s creativity was 
coming into conflict with gameplay. As 
creative director, Hall was insisting on 
continuity in the storyline and trying to 
give the game a plot. As Romero would 
later say, “You don’t need much of a sto- 
ryline if your game is good.” 

“The game designer shouldn’t be 
making a world in which the player is 
just a small part,” echoed Carmack. “The 
player’s the boss; it’s your duty to enter- 
tain him or her.” In the midst of this 
debate and other creative differences, 
Hall left Id to become project manager 
at Apogee. 


Moving On 

After the fallout from Hall’s departure, 
Id crystallized its design ideology. Id’s 
mission is to take cutting-edge technolo- 
gy and turn it into highly playable 
games. [he plot, or lack thereof, in 
Doom is a good example. It involves the 
vague idea of starting in a space station 
and descending into Hell. Doom, and 
presumably all of Id’s future games, 
involves just enough of a storyline to set 
a mood and inject snippets of pop cul- 
ture, mostly from B-movies. Perhaps it 
was Carmack who put it best, “We put 
the player in a dangerous situation and 
basically let the fight or flight instincts 
take over.” 


Another staff split involved Id tak- 


ing over the distribution for Doom 
instead of using Apogee. Although the 
Id staff was pleased initially with 
Apogee, who gave Id its start in share- 
ware games, the staff felt that Apogee 
wasn't equipped to handle the onslaught 
of phone orders that would accompany 
Doom. In an ironic twist, after Id had 
contracted a company called Digital 
Magnetics to handle the phone orders, 
Apogee realized that Id was right about 
its phone order capabilities and ended up 
hiring Digital Magnetics as well. Id con- 
tinues to deal with Apogee with ongoing 
projects such as Wolfenstein II, which 
Apogee will develop itself using a slight- 
ly souped up Wolfenstein engine. Id still 
recommends Apogee to potential game 
programmers as a good place to start. 

With the knowledge that Carmack 
had gained from working on the Raven 
engine, he started work on Doom. The 
Raven engine was much more advanced 
than Wolfenstein. It could render slop- 
ing floors, map texture on any side of a 
cube (in Wolfenstein, a cube had to be 
the same on all sides), allow different 
textures for the ceiling, and create walls 
at angles other than 90 degrees. Unfor- 
tunately, the technology used by the 
Raven engine was as advanced as it 
would get, so to work on Doom, Carma- 
ck had to start from scratch. 

Three revisions later, Carmack had 
a game engine with performance that 
met his expectations. By breaking the 
map down into small sectors and 
reordering them so that the engine was 
able to make use of the 486’s internal 
cache, the engine was optimized for fast 
machines. The final Doom engine has a 
medium detail mode option that doubles 
the pixel width horizontally and triples 
the speed of the game on slower 
machines. Another important addition 
to the Doom engine was allowing all 
objects to have physical characteristics, 
such as weight, momentum, and even 
sound. For example, bullets were actually 
physical projectiles in the Doom engine 
as opposed to Wolfenstein, where they 
were just calculations. Improved AI rou- 
tines allowed monsters to interact with 
each other, and light sourcing gave a 
better sense of depth. 
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Improved Doom Features 
One feature that was built in from the 
beginning was a multiplayer option. Id 
added this feature with an eye toward 
the future. The Doom designers felt that 
multiplayer games would become 
increasingly important as Internet and 
other forms of commercial networks 
become part of more homes. 

Although Id expects less than 10% 
of players of Doom to make use of the 
ability, up to four players can join the 
same game over a Novell IPX network. 
Id designers felt it was important to start 
working on multiplayer games now, so 
they would have the experience when it 
was more crucial to their development. 

As soon as the network option was 
added, however, more complications 
cropped up. For example, the line-of- 
sight checks that the monsters’ AI pro- 
gramming went through were slowing 
the game because they had to scan for 
every player. Another problem with the 
AI routines was that monsters were tar- 
geting some players, but ignoring others. 
These problems were fixed, but there 
was a minor problem that had to stay in 
the game. 

The sprites for the individual play- 
ers were drawn holding a generic gun, 
which wasn’t a big issue when there was 


only one player. But, with multiple play- 
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Figure 2. One of Gregor Punchatz’s Creations 


ers, an opposing player couldn’t tell 


which of the seven different weapons 
another player had. To give the players 
this viewpoint seven complete sets of 
sprites would have to be drawn for the 
character, and the design team felt it 
wasn't that important. 

The graphics for Wolfenstein were 
drawn completely by Adrian Carmack, 
but for the Doom graphics, the Id team 
knew it was going to need help. It enlist- 


ed the aid of professional model designer 
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Gregor Punchatz and created a setup 
that would easily allow the results to be 
digitized. Figure 2 shows the final 
results. 

The models are placed on a revolv- 
ing tray where they are secured to the 
base. There are eight pegs in the tray 
that represent the eight points of view 
that are needed by the game engine to 
render the creatures. Next, the models 
are animated frame by frame by moving 
the model and then rotating it to each 
specific vantage point the engine uses to 
display it. The images are digitized by a 
video camera hooked up to the NeXT 
machine. When each frame is captured, 
it is imported over the network into a 
PC running Electronic Arts’ Dpaint, 
where the photographic source is trans- 
lated into the resolution of the game. 
The images are drawn at full brightness, 
and the game engine varies the contrast 
for light sourcing. 

Sound has generally been a low pri- 
ority in Id’s development process, par- 
tially because there is no sound program- 
mer on staff. Sound quality for Doom 
would be better than in Wolfenstein 
because it was recorded at 11KHz 
instead 7KHz. Id feels that 16-bit sound 
is too much for Doom or any other 
action game in terms of effort, disk 
space, and processor time. Id designers 
were set to support the Roland Sound 


Canvas and most major sound cards, 


DOOM 





when they started receiving angry letters 
from supporters of the Gravis Ultra- 
Sound card. They thought the Ultra- 
Sound card would be too hard and too 
much work to support, but the Id sound 
contractor trimmed down the Gravis 
code and UltraSound support was added 
to the final game. 

As good as the gameplay was in 
Wolfenstein, there was room for 
improvement. Id took advantage of what 
it learned from its experience with 
Wolfenstein to make Doom better. For 
example, secret doors in Wolfenstein 
were often indistinguishable from the 
walls around them, so the only way to 
find one was to search every wall on the 
level. With Doom, all secret doors have 
some distinguishing mark to differenti- 
ate them for the player. More weapons 
were added, each with it’s own unique 
flavor. Unfortunately the biggest 
weapon, the BFG 9000, had to be scaled 
down because it was so elaborate it 
slowed the game to a crawl every time it 
was fired. 

Another enhancement was an auto- 
mapping mode, so players could navigate 
confusing passages from a two-dimen- 
sional, top-down perspective. One delib- 
erate playablity issue that rose from 
adding the automap feature was that 
monsters would not be visible, and new 
mapping doesn’t take place while in 
automapping mode. This limitation 
came about during playtesting because 
once the playtesters were in the automap 
mode, they tended to stay there and not 
play from the actual three-dimensional 
game screen. “The game is not a chal- 
lenge to be efficiently beaten,” said John 
Carmack. “It’s something you're sup- 


posed to experience.” 


Cracking the Doom Crib 

One aspect of Wolfenstein the Id 
designers didn’t plan for was the cottage 
industry of hackers who rose to the chal- 
lenge of hacking Id’s code. Maybe it was 
Wolfenstein’s modem based roots that 
drove people to hack map editors, 
bitmap editors, and sometimes entire 
modified games using the PD 10 level 
teaser file. Apogee contended that all 


these mutations of the game hurt sales 
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because people had in essence much 


more than 10 free levels at their disposal 
for free. 

Id designers take a different view; 
they don’t mind and feel that people 
have the right to make whatever use of 
the game that makes them happy. They 
are planning the same thing with Doom 
and will even release some of the techni- 
cal specifications. But this time, the 
game will run a checksum to verify that it 
hasn’t been altered. If it has been altered, 
it will display a message that says the 
version being played is not the original 
and where to get the original. 

Alpha and beta leaks have plagued 
Id from the beginning, and Doom was 
no exception. In the early development 
stages of Wolfenstein, there was an idea 
to have a contest where whoever found a 
secret room hidden somewhere on one 
of the levels would win $10,000. But the 
first person to call up was a pirate who 
called during the beta testing cycle, and 
the whole prize idea had to be scrapped. 

In the early development of Doom, 
an alpha version of the game made it 
into such wide distribution that people 
were asking the technical support staff 
why the sound didn’t work on their 
machine. The reason, of course, was that 
sound hadn’t been added yet. The most 
disconcerting story has to do with an 
alpha version of the Wolfenstein SNES 
cartridge that was given to handful of 
game magazine editors and somehow 
made into the hand of a pirate in Hawaii 
who was making black market car- 
tridges. To try and keep this kind of 
thing from happening, Id has now set its 
beta policy so that games are password 
protected and tightly controls the how 
many beta copies are distributed. 

Foreign markets are important to 
Id, and designers made a greater effort to 
make games more accessible. ‘They made 
all the characters graphically based not 
font based, so Id can give the graphics 
files to foreign distributors to be trans- 
lated, and the game doesn’t need to be 


recompiled. Foreign orders accounted 
for about 20% of Wolfenstein sales, and 
Id expects foreign orders to make up a 
third of Doom sales due to a better for- 
eign distribution deal. The one snag that 
has lead to various rumors is that 
Wolfenstein has run into trouble in Ger- 
many. Id stated that Wolfenstein is 
banned there, not because of the Nazi 
content, but because of violence, and Id 
expects the same restriction to be placed 
on Doom. 

Despite an average of five calls a 
month Id receives from venture capital- 
ists offering to make the company public 
and big, Id Software is dedicated to 
remaining private and small. Id designers 
feel they have the perfect size for a 
development team that works on one or 
two projects. The Id growth plan 
involves working with other small devel- 
opers and licensors. That plan follows 
what happened with Wolfenstein in 
which Id developed a new piece of tech- 
nology and a showcase game that uses it, 
then licensed the technology to other 
software companies who used Id tools 
and code to make games. In the case of 
Wolfenstein, Id licensed the technology 
to JAM Productions who made Blake 
Stone and Apogee for Wolfenstein II. 

Id plans on developing more 
arrangements like the one it has with 
Cygnus Studios. Cygnus developed 
some games for Apogee that Id liked, so 
Id made an offer to Cygnus to move to 
Texas and work with the Id team. 
Cygnus is now working on a cyberpunk 
role-playing game using the Doom 
engine and all Id’s tools. When the 
Cygnus game is finished, Id will act as 
the shareware distributor. 

After the release of the shareware 
version of Doom. Id will go to work on 
the commercial version of Doom the 
same way it made the Spear of Destiny 
version of Wolfenstein. Doom’s com- 
mercial version will have the advantage 
of its experience in the shareware market 


and any unusual problems that occurred 


with the shareware version will have 
been fixed. This is another aspect of 
shareware distribution that is desirable. 
As irregularities crop up, usually due to 
the variety of hardware in the PC mar- 
ketplace, they can be fixed immediately 
and incorporated into a new revision that 
can be given to the next person down- 
loading Doom off of Id’s bulletin board 


system. 


The Future of Doom 

The next project was to be Doom for the 
SNES, but in making Wolfenstein for 
Nintendo, all that changed. Wolfenstein 
for the SNES was technically very easy, 
it was Nintendo that made it hard. Nin- 
tendo had Id remove the Nazi imagery 
and change the German Shepherds into 
giant rats, which wasn’t a problem. Over 
the next couple of months, Nintendo 
picked over little details and frustrated 
the Id team to the point that it dropped 
all future SNES development. 

The console system that Id is now 
looking at is the Atari Jaguar. The Id 
designers were very excited about it ini- 
tially and were going to develop for it 
after they completed the SNES version 
of Doom. Id is betting that Atari will 
ship over 500,000 Jaguar consoles. After 
their experience with Nintendo, the Id 
designers decided to primarily work for 
the Atari Jaguar. 

After that, it’s off to work on the 
next showcase game. [he subject matter 
hasn't been determined yet, but the tech- 
nology has. The next game engine will 
have true three-dimensional perspective, 
where detailed objects can be viewed 
from any distance or angle. If the Id 
team can keep its high standards of per- 
formance and playablity, maybe it will 
feel compelled to take it easy for a while, 
but don’t bet on it. I 


Alexander Antoniades 1s associate edi- 
tor of Game Developer and assistant edi- 


tor of OS/2 Magazine. 
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entire character of the game changed. 
Instead of carefully studying dozens of 
units and carefully planning their moves, 
players now found they could effectively 
give orders to only a handful of units. 
Ree Oe Instead of having waves of troops 
ee oe Se oe marching inexorably forward, we now 
Wane da had kings marching forth with only a 
few hunting bishops ranging diagonally 
ee Sey to scout enemy positions. Once it had 
| found the enemy, the king could quickly 
gather a few attack pawns and move in 
an for the kill. 

Mat a Pe ace eet ie aad ps Now, the players who did well were 


Feudal, an on-line game available on CompuServe, is a great example of the work those who could think on their feet and 


involved when transforming a single-player or board game into a highly interactive, mul- react to quickly changing conditions. 
tiplayer on-line game. Here, you can learn some of the pros and cons of programming an During this process, I discovered the 
on-line game. first rule of on-line gaming—a true on- 





line game is not just a translation of an 


existing board or computer game; it 





y first on-line game began must adapt and use the advantages and 

as an in-house corporate even the disadvantages of the on-line 

game in 1980. Our compa- environment. 

ny had an enlightened atti- Most existing on-line computer 

tude and encouraged us to games have origins similar to Feudal’s. 

use spare computer time to On-line games can be divided into four 

experiment with new ideas levels of interactivity: 

and improve programming * Solo-against-the-computer. The 
skills. With this time, I created a classic adventure game is an example 
medieval wargame called Feudal. The of these solitaire games. They were 
units were chess pieces traversing a large novel before the PC made its debut, 
terrain map, trying to capture other but there’s no reason to pay on-line 
pieces and opposing kings. Up to 20 charges when you can play similar 
players could play in one game over a games on a stand-alone PC. 
period of weeks. You could examine the ¢ One-on-one. This includes every- 
map, build new units, and give orders thing from tic-tac-toe to chess, as 
for the day, then issue the update order well as advanced wargames. These 
to execute the orders you had given. games also waste host-machine capa- 

During one lunchtime test, we low- bilities and resources; direct modem- 

ered the update time to one minute, and to-modem connections can provide 
the blitz-Feudal (and my first truly the same experience. 
interactive) on-line game was born. The * Some-on-some. Two to 10 players 
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participate in these games. My Air 
Traffic Controller and SNIPER! 
games are examples. 

* Many-on-many. For these games, I 
see hundreds if not thousands of 
players taking an active part in an 
ongoing scenario. A few games tap 
the potential of this last category, but 
none really fulfill that potential. 


The SNIPER! Project 


lll be focusing on the challenges a pro- 
grammer or designer must keep in mind 


when working in the on-line environ- 
ment. I have drawn the examples from 
SNIPER!, a project I first started in 
1987. The first version of SNIPER! 
was released on CompuServe in 1989, 
and the first release of its graphics 
interface Scope was in 1991. Updates 
and enhancements continue. 

SNIPER! is based on a board 
wargame from TSR Inc. and runs on 
CompuServe. It’s a multiplayer, tactical 
combat game, simulating infantry 


actions during World War II. You 


Figure 1. Game Overview for SNIPER! 








Global Segment 
(Table 1) 


Individual Segment 
Slot on host machine 


(Table 3) 
mpslot() in game 


Game Segments 
(Table 2) 





by Stewe Estwanik 





Thinking of getting 
into the multiplayer 
Qame scene? Steve 
tStvanik shares his 

experience program- 
ming his multiplaye 
game SNIPER!. Pro- 
gramming multiplaye 
games can be chal- 


lenging— and fun! 
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GAME 





Table I. Global Database si. i 






nr the entire ee me ae 
Track games started 


— current slot 


_ Selected mission 
__ Selected scenario 
Player rank 








Game spect tlobal data: 





command a squad of soldiers and play 
against one or more other human play- 
ers from around the world. There’s a 
wide variety of missions and scenarios, 
each with a unique map and various 
rules, goals, and challenges. 

In addition to playing SNIPER! 
against other people, you can conduct a 
reconnaissance of any other current 


SNIPER! game. 


you watch your future opponents for 


Reconnaissance lets 


style of play. Do they always attack 
aggressively? Or do they spend time 
carefully setting up their attack? New 
players can get strategy hints or other 
tips by watching two experienced play- 
ers. And as the designer, I can get ideas 
for improvements by directly watching 
what people are trying to do. 

On-line games have a lot of 
browsers, similar to lurkers in forums, 
who far outnumber the more active par- 
ticipants. Although it wasn’t feasible in 
SNIPER!, my goal in future games is to 
involve these lurkers in the actual game 
mechanics by having them drive the 
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Track games finished 
_ Maximun players during a session 
Total players during this session 
Time that first player started (used to count total elapsed time) 
~ Highest number of games in play at a time 





Player nationality in current game 
Job number of each player 
Offset for player, for example, if there are 12 units, seven in the first 
faction and five in second, poff(1) = 0 and poff(2) = 7; thus the first 
unit of a side will be unit(poff(i)+1) : 
_ Number of units for each faction 
Faction of this player, normally 1 or 2 


For each faction, alerts players that the other player's program has 
done something to the unit data 
Flags which units have been changed 
Indicates smoke has changed _ 
___ Indicates rubble has changed 


economy. So even if they don’t come 
back, something in the game will have 
changed or been updated by them being 
there. 


Playing vs. Designing 

Playing on-line games is as different as 
designing them. You don’t have the 
long delays that are standard in phased 
computer games in which each player 
takes control of the computer to enter 
his or her turn. Instead, you must con- 
stantly weigh choices and decide 
whether to spend time on one unit or 
spread your time among several. In the 
game, this can be used to an advantage 
against your opponent. 

You can place one sniper in a 
secure position and just give it orders to 
fire. Your opponent will be forced to 
react to this annoyance, while you can 
be moving other units for an attack 
elsewhere on the map. When your 
opponent uses the same or similar tac- 
tics against you in a different area of the 
map, you'll have the additional choice 


of which of many sectors to concentrate 
on. These complex, chess-like possibil- 
ities and decisions reveal the different 
levels of involvement and challenge that 
are available with on-line gaming that 
cannot yet be achieved against a com- 
puter opponent. 

Scope and other real-time game 
interfaces allow immediate communica- 
tion, but the user can also freeze some 
portions of the action, at least momen- 
tarily. Delays of even a second or two 
can break concentration, so the user 
should not be interrupted when he or 
she is trying to enter a command. 
Thus, in Scope, you can enter a com- 
mand at any time. 

Scope achieves this by treating 
incoming reports in an asynchronous 
fashion, reading data from the host 
character by character. Only when a 
proper terminator is found does the 
program decide whether to display the 
on-screen results or merely store the 
new data for later queries. While this is 
occurring, you can enter new com- 
mands or move the map or gather other 
information. You can even combine 
these operations. 

For example, while entering a 
command, you can stop, use the mouse 
to scroll the map, gather specific infor- 
mation about unit location or terrain, 
then return to the half-completed com- 
mand and use that information to give 


This con- 


trasts with a mode-based system in 


more precise coordinates. 


which you are either in command mode 
or map mode and cannot easily mix 
operations from the two modes. 
Eliminating modes makes a more 
realistic interface for the user, but places 
extra efforts on the designer and pro- 
grammer to ensure that all features are 
available and cooperate with each other. 
This is one of the keys to interactive 
The player should 


always be able to execute some type of 


on-line games. 
action. (Games such as chess and 
backgammon are usually less interesting 
as on-line games because players must 
wait for their opponents to take their 
turn. (This is particularly true of games 
with a connect charge from an on-line 
service. ) 
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SUBSCRIBE TO THE 1994 
VIRTUAL REALITY SPECIAL REPORT' 





ve S | Please place my Charter Subscription order to the Virtual 


Reality Special Report for $32 for all 4 1994 issues. I’ll save almost $8.00 off 
the cover price! 
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MULTIPLAYER 





Table 2. Game Segment Data | 





items — Description 
- trucenegotiated Game ended with a truce 
firstshotfired Has first shot or grenade been fired? 
tpanicrecovery Time at which next panic recovery can occur 
__ endofgame Can be triggered by either player; this is the variable that plucks 
a players from the game 
smoking There is smoke somewhere on the map 
tdrift If smoking, the time that the smoke will drift 
—— mpslot() Slots of the participating players 
~— nrubble- Number of rubble areas 
rublist() For scope, lists all rubble coordinates 
smap() Current terrain for map coordinates 
—-umap() Shows where units are on the map for easier checking 
— msgflag() Signals a message is waiting for this player; allows any number of 
| real players 
smoke() Smoke locations - 
smokeopen() Open slots in smoke array 
_ order.stack() Pending orders stack 
mit Current soldier information 


Some soldier parameters include: 


_ Parameter Description 
OWNER __ Slot of player 
FACTION Same as plside() 
GROUP Subdivisions of a faction 
oe Row location 
JLOC Column location 
FACING Direction unit faces 
ACTIVATION Activation rating, a value from 1 to 5 
MSI Tactical status, one of the following: normal, moving, evading, 
(_ ~=—sCCUprone., and cargo 
COND Condition, one of the following: normal, wnd, inc, kia, oob 
TPANIC Time of next panic check; 0 equals no panic, otherwise time 
ce for next check 
ri Relative panic rating from 2 to 5 
—LASTNOVE Time of last move 
NEXTTASK Time for next move 
SIGHT Sighting and exposed flag 
— WPN Weapon number 
—WPNSTAT Weapon status 
SGRENADE Number of smoke grenades 
FGRENADE Number of fragmentation grenades 
Considerations interplayer communication. Related 


On-line, multiplayer games pose chal- 
lenges similar to those of designing 
other real-time programs, so some 
experience with interrupts, interjob 
communications, and shared data is 
helpful. Compared with other comput- 
er games, multiplayer games have sever- 
al additional design considerations, 
including game start up and ending and 
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design problems include keeping the 
game interesting for both sides at all 
times and providing an enjoyable gam- 
ing experience in a designated amount 
of time. 

Most board games and many com- 
puter games use some sort of pulsed or 
sequential movement. It’s difficult to 
make a reasonable, simultaneous action 


GAMES 


game without a computer. For board 
games, the best that can be done is to 
allow players to write orders and try to 
execute all the orders at the same time. 
Or you can use a third, nonplaying 
umpire to control the game. 

A real-time game has a completely 
different feel to it. In SNIPER!, the 
action is constant. You never need to 
wait for your opponent. Instead, you 
have your squad carry out your plans 
and react to the enemy’s moves as you 
become aware of them. Continuous 
action necessitated a major overhaul of 
the original board game’s features. 
Pulses, rounds, and other stepwise parts 
of the game are gone. No longer are 
there recovery phases, but then, in a real 
battle, the two sides don’t stop for sev- 
eral minutes while people go running 
around trying to help others recover 
from panic or passing out “end of 
round” indicators and activation chits. 

The basic feel of most board games 
is that of a series of specific segments 
with specific tasks to be performed in 
each segment. For on-line games, you 
never want to leave one player waiting 
while the other player is making deci- 
sions. In SNIPER!, I reworked the 
original board game phases to form a 
smooth-flowing background of activity. 
An important element in achieving this 
goal was my redesign of the activation 
concept 

Instead of moving a set distance or 
sighting and waiting for one of several 
phases, all activities take place whenever 
a particular soldier is ready to perform 
them. Once any activity occurs, an 
activation rating determines the next 
time a soldier can act. The main pro- 
cessing portion of the host program 
looks to see if either side has orders that 
are ready to be executed. Each com- 
mand takes a variable amount of time to 
be executed, so orders are “stacked” for 
each soldier. This lets you give multi- 
ple commands to one or more soldiers, 
then move elsewhere. 

A welcome side effect of this strat- 
egy is the minimization of the influence 
of baud rate (speed of transmission) 
used by the opponents. Each person’s 
job will execute the next order on the 





stack, no matter which side that unit 
belongs to. So some orders of each side 
are executed by the slow player’s job 
and some by the fast one. 

I changed the activation ratings 
from the board game concept to create 
simultaneous, real-time action. In the 
board game, a die roll decides whether 
particular units can move or act. In my 
game, activation indicates the probable 
time until the next action. From the 
game charts, I extracted four variables 
that describe a unit’s activation: an 
overall evaluation of the performance of 
a unit—the track and activation ratings, 
the number of expected rounds, and a 
small random factor. 

Thus a track A unit in the board 
game could expect to be active up to six 
rounds. The time between simple 
actions in the on-line game is between 
four and 14 seconds. Contrast this to a 
type H unit whose time between similar 
actions is 10 and 25 seconds. These 
numbers were determined experimen- 
tally, and the tracks vary according to 
nationality and scenario. They have to 
have some spread, but not too much, or 
the game will be unbalanced. The 
details aren’t published. Instead, play- 
ers know that a track A is faster than a 
track B but not necessarily by how 
much. 


Mapping and Sighting 
Another major change in moving from 
a board game to a computer game was 
the map shift. People relate more natu- 
rally to a square grid, where left, right, 
and diagonal have obvious meanings, 
while a hex map simplifies the design- 
ers job. On the computer, diagonal 
and sideways movement are easy to cal- 
culate correctly. Thus, while your 
squad faces in one direction, it can 
move in several other directions relative 
to its facing. This lets you fall back, for 
example, while maintaining covering 
fire against anyone foolish enough to 
run after your retreating squad. 

Sighting requirements are different 
for on-line games. In SNIPER!, any 
unit can sight and fire once a unit is in 
sight. ‘This eliminates the need for spe- 
cific-opportunity fire rules. We avoid 


pljob (sender) pljob (sender) 
curgame (slot) curgame (slot) 
mapnum mapnum 


Table 3. Individual Player Data During a Mission 


: | Allows end of this player's mission without 
: ee 








Two-Player Multiplayer 





ptr to next player (5, 6, 7) 
Second player 

Third player 

Fourth player 


Table 5. Global Lock Parameters 


: —_— | 


ganepoints, hitpoints, reservation 
~ curgame, gstatus, lvlopp 

_ radioflag(), radiomsg() 

Hall of Fame updates 








Items Affected 


Unit array 
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the board game problem of having units 
that are in known positions but that 
can’t be fired on because there’s no cur- 
rent spotter. 


Grenades and Smoke 

There’s added realism beyond the board 
game by having walls, floors, bridges, 
and trees turn to rubble when hit by an 
explosion. Similarly, rubble can be 
added to maps before play starts, 
increasing the unpredictability, since 
the rubble will be random in degree and 
placement. 

Smoke is generated from any 
explosion or from special smoke 
grenades. Each game has a wind direc- 
tion so the smoke drifts, persists for 
awhile, then fades. Smoke inside a 
building persists longer, making it diffi- 
cult to find people inside. Fires some- 
times start and spread out of control. 


Technical Challenges 
This section describes the very different 
approach to program design that’s 
required for an on-line game. Sharing 
data among users in traditional, single- 
microcomputer games is quite simple, 
since everything is either in memory or 
on a disk. For an on-line game, you 
need to decide how players will com- 
municate. You need to design different 
segments of data that can be shared by 
different classes of users. This affects 
subsequent programming problems. 
Figure 1 shows my solution for 


SNIPER!. At the top is the global 
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dataset, and the contents of this seg- 
ment are shown in Table 1. This gen- 
eral information is available to any play- 
er at any point in the game. It includes 
player names, current status of each 
player, the state of the game, messages 
among players, and timing information. 
Once a game is started, the only people 
who need the individual game data are 
the actual players and any watchers, so 
each game has its own data segment 
attached, as shown in Table 2. 

Thus, you can swap these segments 
in and out of memory as needed rather 
than try to guess some optimum 
amount of memory at the start and then 
either have too much unused memory 
or not enough for the demand. Finally, 
users carry with them a quantity of per- 
sonal data, such as points scored, as 
shown in Table 3. So, in Figure 1, 
players 1 and 3 are playing sides A and 
B in game 1. They have their own data 
segments and share that for game 1. 
They also share the global data area 
with all other players. Similarly, when 
player 6 decides to recon game 2, being 
played by players 4 and 5, player 6’s job 
locates the game 2 data segment and 
attaches to it to be able to watch the 
game. Player 2 is logged into the game, 
but not attached to any game segment. 

All these different data segments 
are, of course, transparent to the play- 
ers. But this choice gives me flexibility 
I might not have with other schemes. 
For example, when a game starts, I first 


read a copy of the map into the game 


segment. By making copies of the 
maps, each game starts with the same 
map but is free to change it as the game 
progresses. Thus, explosions can have 
immediate effects on the terrain. Or, 
random pregame bombing can be 
invoked to destroy part of the terrain. 
Thus, the maps, while similar, differ 
slightly for each game. 

A series of interprocess communi- 
cation facilities (IPCF) sends messages 
from one job to another. One job starts 
a game, sets up the map and terrain, 
then signals the other player or players 
that the game is ready. Table 4 shows 
the IPCF used for one-on-one and 
multiplayer synchronous starts. In the 
two-player version, the first job sends 
an IPCF consisting of the sender’s job 
number, current game number, and 
map number. 

The receiving player’s job uses the 
current game number to look up the 
address of the game segment, and the 
map number to ensure that both players 
are using the same map. (Current game 
numbers are not predictable, since many 
games can begin and end during a ses- 
sion, and the numbers are recycled.) 

For multiple players, the IPCF is 
more complicated, since no player 
should be allowed to enter orders until 
all have been linked into the game. 
Because of locking, only one player at a 
time can gain access to the game seg- 
ment, so a cascading design works here. 

Player A starts the game as before, 
then sends an IPCF to player B. Now, 
the IPCF includes the slot numbers of 
players C and D, too. When player B is 
set up, his or her job sends a similar 
IPCF to player C. (The only change is 
that the pointer now points to player D, 
rather than C). After D is attached to 
the game segment, his or her job still 
has the addresses of the other players, 
so a message can be sent to all jobs that 
allows the players to start the game. 

Normally, each attachment to a 
game segment takes about one second, 
but if the system is slow, the entire 
process might take 10 seconds or more. 
This design ensures that the startup 
procedure will work no matter what 


delays occur. It can also handle the sit- 





rent state. The registers are numbered 
from 0 to 255. To change a register, you 
OUT to the register select port what regis- 
ter you want to modify and OUT to the 
data port what new value (from 0 to 255) 
you want to set the register to. 

There’s a complication: the AdLib 
soundboard takes a while to respond to 
your requests. The best way to estimate 
the correct wait time is to poll the 
AdLib’s register because that takes the 
same length of time no matter what 
microprocessor you're running 
(although future AdLib compatibles 
might change that response time). 

After you write to the register selec- 
tor, poll the AdLib’s register seven times 
(with the assembly language IN 0x388 
command or the C inp(0x388) function). 
After you write to the data register, you 
have to poll the AdLib’s register 35 
times. 

Listing 1 shows the MAIN.C pro- 
gram. The function write_to_reg() gives 
an example of this procedure. 
write_to_reg() actually performs the data 
delay before the address write, which has 
the same effect as doing the data delay 
after the data write when write_to_reg() 


is called over and over again successively. 


What the Registers Do 
Different bits of a register have different 
functions. For example, in registers 0x20 
to 0x35, bits 0 to 3 determine the fre- 
quency of the oscillator, and bits 4, 5, 6, 
and 7 each has its own special function. 
When writing to a register, therefore, 
you have to know what you want every 
bit to do before you call outp(). I set up 
the entire byte first and then call 
write_to_reg(). 


Listing 1. MAIN.C 


//MAIN.C: The Cheezy Synthesizer program, by Jamie Fristrom 
#include <stdio.h> 
#include "fm.h" 


PatchData sample_patch = { 
(1<<5)|(15), // sustaining and pitch multiplication of 2 (opi) 
(1<<5)1(7), // sustaining and pitch multiplication of 3 (op2) 


0, // no attenuation or scaling for higher pitches (op1) 
0, // no attenuation or scaling for higher pitches (op2) 
Oxf0, // fast attack, slow decay (op1) 

Oxff, // fast attack, fast decay (op2) 

Oxf8, // loud sustain, medium release (op1) 

Oxf8, // loud sustain, medium release (op2) 

0, // sine wave (opt) 


3, // pulse sine (op2) 
(3<<1)|(1) // PI/4 feedback, FM syntehsis mode 
}; 


void main(void) 


char key; 
int block,note; 


printf("\nCheesynth by Jamie Fristrom."); 
printf("\nHit letters to play notes."); 
printf("\nHit numbers to play drums:"); 
printf("\n 1) High hat."); 

printf("\n 2) Cymbal."); 

printf("\n 3) Tom."); 

printf("\n 4) Snare."); 

printt("\n 5) Kick."); 

printf("\n\nPress enter to quit.\n"); 


fm_reset(); // Reset the chip. 

init_drums(); // Set up drums. 
write_patch(&sample_patch,0) ; // set channel 0 to play our cheezy sample 
fort; ;) 

{ 


key = getch(); 
if (key==13) break; 
if ((key>="1’)&&(key<="5*)) 


i! 
key-="1°; 
stop_drum(key) ; // easy way to make sure a drum is stopped 
// cutting into its decay time 
play_drum(key) ; 
else 
{ 
key-=" a"; 
// split octave off of note 
block = 2+key/12; 
note = key/12; 
play_voice(0,block,note) ; 
stop_voice(0); // since we can’t detect when user lifts his or her 
// finger from keyboard, stop voice right away. 
} 
} 
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In cases where you want to leave 
certain bits on the register unchanged, 
save what you set the register to the first 
time you wrote to it in a variable and use 
that information again the second time. 
An example of this in shown in Listing 1 
in the function stop_voice. I didn’t use 
bit fields in the source code to describe 
these registers because bit fields get 
implemented differently by different C 
compilers. 

These registers affect the function- 
ing of the whole chip. The function 
fm_reset(), shown in Listing 2, shows an 
example of initializing them. The test 
register occupies bits 0 to 4 of register 
0x01. This register must be initialized to 
zero. The wave select enable register is 
in bit 5 of register 0x01. This register 
allows you to use wave forms other than 
sine waves with your operators. If the bit 
is on, the value in an operator’s wave 
select register will be used to determine 
what kind of wave the operator uses. 

Timers and status registers are 
located in registers 0x02, 0x03, and 0x04. 
The OPL2 has timers built into it, 
which were intended by Yamaha to be 
used to interrupt the computer so you 
could sequence your music. However, 
the timers aren’t actually hooked up to 
interrupt requesters on the sound card, 
so you can’t actually do that. You can use 
them to tell whether there’s a frequency 
modulation chip hooked up to register 
address 0x388 or not, but that’s beyond 
the scope of this article. For now, just 
leave them alone. 

The note-select flag is in bit 6 of 
register 0x08. [This determines the key- 
board split point, but, for our purposes, 
it doesn’t matter what this is set to. It 
sounds the same either way. 

The synthesis mode register is in bit 
7 of register 0x08. This determines if the 
frequency modulation chip will function 
in music mode or speech synthesis mode. 
We set it to 0 for music. The amplitude 
modulation depth register is in bit 7 of 
register 0xBD, and the vibrato depth reg- 
ister is in bit 6 of register OxBD. 

If amplitude modulation depth is 
on, the depth of note tremolos are dou- 
bled. If vibrato depth is on, it doubles 
the depth of note vibratos. I just leave 
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these on under the premise that the 
noisier the tone is the better. Of course, 
I’m a big fan of industrial-strength heavy 
metal. You can do what you like with 
them. Register 0xBD is also used for 
drums, which [ll be explaining. To 
make sure drums are off, set bit 5 to 0. 


The Operators 

There are nine voices, with two opera- 
tors each. Thus, there are 18 registers 
for every operator parameter you can set. 
Each voice has a modulator and a carrier, 
as mentioned previously. Table 1 shows 
how to find the proper register for a 
given operator. 

The offset determines which regis- 
ter in a set belongs to the operator you 
want to modify. For example, the attack 
rate and decay rate registers start at 0x60. 
If you want to modify the attack rate and 
decay rate for the carrier of voice 6, you 
use 0x60+0x13 or 0x73. As you can see, 
there’s little rhyme or reason to the chart 


Table 1. Finding the Proper Register 


VoIcE OPERATOR 
0 Modulator 1 
Carrier 4 
{ Modulator 2 
Carrier 5 
2 Modulator S 
Carrier 6 
Modulator 7 
Carrier 10 
4 Modulator 8 
Carrier i 
5 Modulator 
Carrier +2 
6 Modulator 13 
Carrier 16 
1 Modulator 14 
Carrier {7 
8 Modulator 15 
Carrier 18 


Operator No. 


OFFSET 


Ox00 
Qx03 


Ox01 
Ox04 


Ox02 
Ox05 


0x08 
Ox0b 


Ox09 
Ox0c 


Ox0a 
Ox0d 


Ox10 
Ox13 


Ox1 1 
Ox14 


Ox12 
0x15 





of offsets. All you can really count on is 
that a voice’s carrier is three higher than 
its modulator. Shown in Listing 2, 
write_patch(PatchData *pd, int voice_no) 
is an example of how to computer regis- 
ter examples for a given voice voice_no. 


The Operator Parameters 
The multiplication factor takes up bits 0 
to 3 of registers 0x20 to 0x35. This deter- 
mines the frequency at which the oscilla- 
tor oscillates by multiplying the frequen- 
cy of the voice. For example, when you 
set the multiplication factor to 2, the fre- 
quency of the oscillator is twice the fre- 
quency of the note. But it’s quite simple: 
some of the factors have weird results. 
When the multiplication factor is set to 
0, the pitch gets divided in two; when 
it’s 11, the pitch gets multiplied by 10 
rather than 11; when it’s 13, the pitch 
gets multiplied by 12 rather than 13; 
and when it’s 14, the pitch gets multi- 
plied by 15 rather than 14. 

When you set the multiplication 
factor in frequency modulation synthesis 
mode, the pitch of the modulator deter- 
mines the pitch of the note. The pitch 
of the operator just determines a sort of 





Sine Wave 


Absolute Sine 


Clipped Sine 


Pulse Sine 


Figure 1. Four Different Types of Wave Forms 


color. I find you get more interesting 
sounds if the two frequencies are not 
related to each other, like 5 and 7, for 
example. In additive synthesis, the two 
frequencies will just combine to make a 
voice barely more complicated than a 
sine wave. You can also create interest- 
ing effects by having high multiplication 
factors and then playing lower notes. 
The key scale rate bit is bit 4 of reg- 
isters 0x20 to 0x35. This makes envelopes 
for the operator shorter when higher 
notes are played and helps simulate 
stringed instruments; with stringed 
instruments, higher notes last less time. 
The envelope type occupies bit 5 of 
registers 0x20 to 0x35. When it’s on, the 
operator will continue playing at the sus- 
tain level until the key-on bit is set to 0. 
When it’s off, the operator doesn’t sustain. 
The vibrato parameter occupies bit 
6 of registers 0x20 to 0x35. ‘This parame- 
ter turns the frequency vibrato on or off 
for a given operator. It’s a fast vibrato— 
6.4Hz. The amount of vibrato for all 
the operators can be controlled by the 
vibrato-depth bit. 
The amplitude-modulation para- 
meter occupies bit 7 of registers 0x20 to 


0x35. This is a fast tremolo—3./Hz. 
The depth for all the operators can be 
controlled by the amplitude-modulation 
depth bit. 

The total level parameter are locat- 
ed in bits 0 to 5 of registers 0x40 to 0x55. 
This parameter indicates the volume. 
The tricky part is that volume goes down 
as this number goes up, so setting the 
total level to 0 is the loudest. Setting it 
to 63 is silent. 

When setting the total level, in fre- 
quency modulation mode, adjusting the 
carrier is what really effects the volume 
of the note. Adjusting the volume of the 
modulator changes the timbre. You 
don’t need a lot of modulator depth to 
have interesting-sounding notes. Exper- 
iment with just a little modulator at first 
and then increase the amount of it. 

The key scale level is located in bits 
6 and 7 of registers 0x40 to 0x55. Some 
real instruments, such as pianos, get qui- 
eter as their pitch goes up. This parame- 
ter lets you emulate that affect. Setting 
bits 6 and 7 to 0 means no change for 
higher pitches. Setting just the high bit 
to 1 gives the first level of attenuation, 
setting just the low bit to 1 gives the sec- 


In frequency 
Modulation, you 
get more interest- 


ing Sounds If 


frequencies are 


not related . 
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// Code for programming AdLib 


Listing 2. FM.C (Continued on p. 41) 


// Jamie Fristrom 
// November 1993 
#include <dos.h> 
#include <conio.h> 


#define ADLIB_ADDR_PORT 0x388 
#define ADLIB_DATA_PORT 0x389 


#include "fm.h" 





// The op_offsets are the offset to a given address to find the parameter 
// for the first operatof for a given voice. The second operator is 
// always three after the first one. 


static int op_offset[] = { 


ond level, and setting both bits to 1 gives 
the third level. 


The Operator Envelopes 

The envelope determines how loud the 

operator gets over time. Changing the 

envelope of the carrier affects the enve- 

lope of the voice. Changing the enve- 

lope of the modulator affects the timbre. 

The envelope has four parts: 

* The attack, which is how quickly the 
sound builds to its loudest point 

* The decay, which is how quickly a 
sound diminishes to its sustain level 

¢ The sustain level, which is the frac- 


tion of the maximum level that the 


0, // voice 0 ~— 

{ I voice 1 sound hovers at while the key is being 
2. // voice 2 pressed down 

8, // voice 3 * The release rate, which is how quickly 
9, // voice 4 the sound diminishes to silence after 
10,  // voice 5 the key is released. 

6, ff voice 6 The sustain level only matters if the 
17, // voice 7 envelope-type bit is set. For the rates of 
18, // voice 8 


static int fnumber[] = { 


these four envelope parts, the higher the 
number, the shorter the time each part 
takes. 

The attack rate occupies bits 4 to 7 


ix, «ff of registers 0x60 to 0x75. This rate deter- 
oe. a mines how quickly the sound gets loud. 
Oxtet, f/0 A high value emulates a quick-attack 
Ovi9s, = // OF instrument like a guitar; a low value 
Oxibo,  //E indicates an instrument that builds up 
eae : # sound slowly like a woodwind. 

0x202, // G The decay rate is found in bits 0 to 
0x220,  // Gt 3 of registers 0x60 to 0x75. This rate 
Oo, fk determines how quickly the note drops 
01263, =i to its sustain level. A twangy electric 
Gr7ar, 7/1 B guitar, for example, starts of with a 


\e 


static char reg_shadow[9]; 


void write_to_reg(char reg,char value) 


{ 


int i: 


// Data delay: putting it here protects us from nested interrupts, 


quick, loud burst of noise and drops to a 
much smaller sustain level. It would 
have a high decay rate. 

The sustain level occupies bits 4 to 
7 of registers 0x80 to 0x95. The sustain 
level is the fraction of the maximum vol- 


ume at which the operator remains while 


the key is held down. We indicate that 
the key is held down by leaving the key- 


// not that we need to worry about that in this program. 
for (i=0;i<35; i++) 
inp(ADLIB_ADDR_PORT) ; // wait until we’ve done 35 ins 
// Select what address on the card we want to write to. 
outp(ADLIB_ADDR_PORT, reg) ; 
for (i=0;i<7;i++) 
inp(ADLIB_ADDR_PORT) ; 


outp(ADLIB_DATA_PORT, value) ; oul 
} nothing after the key-on bit is turned 


off. 


The wave select parameter is found 


on bit for the voice on. As soon as we 
turn it off, the music volume will fall off. 


The release rate occupies bits 0 to 3 
// I read literature that said 6. It was wrong. 


HF eit for instances of registers 0x80 to 0x95. The release rate 


is how quickly the volume drops to 
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in bits 0 to 1 of registers 0xE0 to OxF5. If ST 2. FM. (Continued on p. 42) 
the wave-select bit in register 0x01 is set, 

we can use this parameter. Changing the void write_patch(PatchData *pd,int voice_no) 
wave of a carrier or a modulator has qual- // Writes a patch to the sound chip. 


{ 
int addr; // Address offset for operator. 
int volume; 





itatively different effects. For example: 
* OQ isan ordinary sine wave. 
* 1 is a clipped sine wave. (Negative 
values are treated as zero.) addr=op_offset[voice_no]; 
* 2 is an absolute-value sine wave. 
(Negative values are made positive.) write_to_reg(0x20+addr ,pd->flags1) ; // am/vib/eg/ksr/multi 
* 3 is a pulse wave. (Somewhat like a write_to_reg(0x20+3+addr , pd->flags2) ; 
jagged sawtooth wave missing every 
other tooth.) // It’s often useful to reset the attenuation of the two 
// two operators for every not you play, so you can have 
// accents. We’re not doing that here. 
write_to_reg(0x40+addr,pd->ksl_attni);  // ksl/attenuation 
write_to_reg(0x40+3+addr , pd->ksl_attn2) ; 


Figure 1 shows the four different 
types of wave forms. 


One-Register-per- 

Voice Parameters write_to_reg(0x60+addr , pd->att_dec1) ; // attack/decay 
The remaining parameters specify how write_to_reg(0x60+3+addr , pd->att_dec2) ; 

the operators are to be connected, and 

thus there’s only one per voice. The off- write_to_reg(0x80+addr ,pd->sus_rel1) ; // sustain/release 
sets for these are easy, that is, voice 1 has write_to_reg(0x80+3+addr ,pd->sus_rel2) ; 


an offset of 0, voice 2 has an offset of 1, 


and so on. For example, if you want to write_to_reg(Oxe0+addr ,pd->wave_sel1); // wave select 


: ' ; write_to_reg(0xe0+3+addr , pd->wave_sel2) ; 
set the connection bit for voice 7, the g( P ) 


connection bits start at register 0xCO or write_to_reg(0xc0+voice_no,pd->fdbk_alg); // feedback/algorithm 
OxCO + 7 = OxC7. } 
The connection bit is bit 0 of regis- 
ters 0xC0 to 0xC8. When set to 0, the void fm_reset (void) 
operators are connected together in the { 
frequency-modulation mode. When set // This will silence the fm chip and make it ready for programming. 


to 1, the operators are connected togeth- int 1; 
er in the additive-synthesis mode. Addi- 


, write_to_reg(0x01,0x20); // Initialize test register to zero and indicate 
tive synthesis just adds the outputs of the 


// that value in WS should be used to select waves. 


two operators together; its a lot less write_to_reg(0x08,0x20); // Standard music mode. (Rather than speech 

interesting than frequency modulation. // synthesis) Keyboard split is second bit from 
The feedback parameter is found in // MSb of F-number. 

bits 1 to 3 of registers 0xC0 to OxC8. Just write_to_reg(0xBD,0xCO0); // Turn on am and vib. All drums off. 

like the modulator can be used to modu- // am and vib help make music a little "noisier". 


late the carrier, it can also be used to 
// Turn off all voices 


for(i=0;i<9;it+) { 
write_to_reg(0xA0+i,0x00) ; 
write_to_reg(0xB0+i,0x00) ; 


modulate itself, sending its output to its 
own input. This can add even more tim- 


bre to your sound. ‘This works for addi- 


tive synthesis as well. The amount of } 
feedback is specified by setting this para- } 
meter from 0 (for no feedback) to 7 (for 
maximum feedback). void set_frequency(int voice_no,int octave,int note) 
// Same as play_voice, but doesn’t set Key_on: used for initializing 
Finally—Playing a Note // drum frequencies. 
Now that we've set all the parameters for { a 
' : unsigned char key_oct_fn; // key on/off, octave, and hi bits 
a given voice, we can finally ask the 
vanced ten allbeewce waists. MEL , of frequency get all rolled into one here 
ea Joe int fnum = fnumber [note] ; // get the frequency specifier 


setting the frequency of the note and write_to_reg(OxA0+voice_no,fnum&Oxff);  // write low bits of frequency 
turning on the key-on bit. 


The frequency is divided into two 
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Listing 2. FM.C (Continued on p. 43) 





key_oct_fn = ((octave&0x03)<<2) | ((fnum>>8)&0x03) ; 
reg_shadow[voice_no] = key_oct_fn; 
write_to_reg(0xB0+voice_no,key_oct_fn); // write hi bits of freq, block # 


// and turn the note on. 
} 


void play_voice(int voice_no,int octave,int note) 

{ 
unsigned char key_oct_fn; 

of frequencyget all rolled into one here 
int fnum = fnumber[note] ; // get the frequency specifier 
write_to_reg(OxA0+voice_no,fnum&Oxff);  // write low bits of frequency 
key_oct_fn = 0x20] ((octave&0x03)<<2) | ((fnum>>8)&0x03) ; 
reg_shadow[voice_no] = key_oct_fn; 
write_to_reg(0xB0+voice_no,key_oct_fn) ; 


// key on/off, octave, and hi bits 


// write hi bits of freq, block # 
// and turn the note on. 


li 


void stop_voice(int voice_no) 
{ 
write_to_reg(0xB0+voice_no,reg_shadow[voice_no]&0x1f) ; 
} 
static char shadow_0xBD; 


// Patch for bass drum 
PatchData drum_patch_6={ // this, and voice_6 frequency, determinem sound of 


// bass drum. 


00, // not sustaining and pitch multiplication of 1/2 
(op1) 

00, // not sustaining and pitch multiplication of 1/2 
(op2) 

OxB, // attenuate modulator a little 

0, // no attenuation on carrier 

Oxa8, // medium attack on modulation, medium decay (op1) 

Oxd6, // fast attack, slow decay on carrier (op2) 

0x4c, // little sustain, quick release (op1) 

Ox4f, // little sustain, quick release (op2) 

0, // sine wave (op1) 

0, // sine wave (op2) 

0 // no feedback, FM syntehsis mode 


7; 


// drum patches 7 and 8 do not determine the sounds of individual 

// drums, rather each register has an effect on some of the drums, 

// but not others. I’ve used trial and error to come up with drums 

// that sound okay. Same goes for frequencies 7 and 8. 

PatchData drum_patch_7 = { 
0x01,0x0c,0x06,0x00,0xF9,0xF8,0x68,0xB5,0x00,0x00,0x01 

}; 


PatchData drum_patch_8 = { 
0x02,0x03,0x00,0x05,0xF7,0xF5,0xb5,0xa5,0x00,0x00,0x01 
Ve 


void init_drums(void) { 
ant i: 
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parts: the octave and the frequency 
number. The frequency number is a 10- 
bit number. The lower eight bits of it 
are kept in registers 0xA0 to 0xA8 (one per 
voice), and the two high bits are kept in 
bits 0 and 1 of registers 0xB0 to OxB8. 

The frequency number is no¢ the 
frequency in Hz. The fnumber[] array in 
FM.C is a table for looking up the fre- 
quency number given a note value (0 is 
C, 1 is C#, and so on). This is shown in 
Listing 2. The octave is kept in bits 2 to 
4 of registers 0xB0 to 0xB8. Octave 4 con- 
tains middle C. 

The key-on bit is bit 5 of registers 
0xB0 to 0xB8. For example, when playing 
middle C with voice 7, set register 0xA7 
to 0x58. (0x58 is the low byte in 0x158, 
the frequency number for middle C.) 

Then, set register 0xB7 to 0x31; in 
binary, that’s 00110001. The first two 
zeros are meaningless. The next 1 is the 
key-on bit, telling the chip to play. The 
next 100 is bit 4, the octave number. 
The next 01 is the high two bits of 0x158, 
the frequency number for middle C. To 
turn the note off, we should set register 
0xB7 to 0x11. That will leave the fre- 
quency the same while the note is 
released. 


Drums 

One last thing to mention is drum 
mode. In normal operation, the OPL2 
has nine voices, all intended to play 
melodic instruments. But, you can enter 
rhythm mode by setting bit 5 of register 
0xBD. In rhythm mode, the first six voices 
are melodic instruments, and you also 
get five drums, powered by a white-noise 
generator. 

When the OPL2 is in drum mode, 
you have to make sure the key-on bits 
for voices 6, 7, and 8 are off. Then, you 
can use bits 0 to 4 of register 0xBD to 
make drum sounds: 

Bit 0 contains the high hat sound, 
with volume controlled by operator 14 
(offset 0x11). Bit 1 contains the cymbal 
sound, with volume controlled by opera- 
tor 18 (offset 0x15). Bit 2 contains the 
tom sound, with volume controlled by 
operator 15 (offset 0x12). Bit 3 contains 
the snare sound, with volume controlled 
by operator 17 (offset 0x14). Bit 4 contains 





the bass drum sound, with volume, patch 
and frequency controlled by voice 6. 

Like playing notes with the key-on 
bit, to make a drum sound, you have to 
turn the bit from 0 to 1. (So, after you 
turn a drum bit on, you have to turn it 
off before you can turn it on again.) 

Changing the timbre and frequency 
of the drums is not very simple. You 
can't just change the frequency modifier 
for operator 17 to change the pitch of 
the snare drum because the sound of the 
high hat gets changed too. I don’t know 
why the relationship of operators to 
drums isn’t more sensible. I’m sure 
Yamaha had a reason for making it that 
way, but none of the manuals I’ve seen 
explains this phenomenon. 

The same problem goes for setting 
the pitch of the drum sounds. Modify- 
ing the pitch of voice 6 only affects the 
bass drum, but the pitches for voice 7 
and 8 can affect all the remaining drums. 

In the source code, init_drums() sets 
up the drum sounds to sound okay. (It’s 
as good as I could make it. The cymbal 
sounds awful, I know. Feel free to 
experiment with them.) 


The Sample Source Code 
The sample source code in Listings 1, 2, 
and 3 shows how to program voices and 
make them play. The code was com- 
piled using Zortech C++ 3.1. Listing 1 
is MAIN.C. This is an example of how 
to use FM.C and FM.H to turn your 
computer into a cheezy musical instru- 
ment. Listing 2 is FM.C. This is where 
all the functions for activating and using 
the AdLib are. Listing 3 is FM.H and 
contains some useful data structures and 
function prototypes for FM.C. 

A structure for holding the data for 
a given voice is in FM.H, called PatchDa- 
ta. The elements of PatchData corre- 
spond to various registers on the chip. 
For example, flagi is for registers 0x20 to 
0x35: the amplitude modulation, the 
vibrato, the envelope bit, the key scale 
rate, and the frequency multiplier. 

The functions in FM.C work as 
follows. write_to_reg() sets a given reg- 
ister on the AdLib soundboard to a 
value. To turn drum mode on, for 
example, you would use the line 





Listing 2. FM.C (Continued from p. 42) 





// Turn KEY-ON registers for fmchannels 6,7,8 off. 


for (i=6;i<9;i++) 
stop_voice(i); 


// Okay, go drums. 
write_to_reg(0xBD,0xE0); 
shadow_OxBD = OxE0; 


// Set up drum patches 

write_patch(&drum_patch_6,6); 
write_patch(&drum_patch_7,7); 
write_patch(&drum_patch_8,8); 


// leave am and vib on 
// save information about how we set register 


// Set up drum frequencies : I hit upon these by trial and error. 


set_frequency(6,2,1); 
set_frequency(7,2,2); 
set_frequency(8,2,3); 


} 
void play_drum(int drumno) 
{ 
char outbyte; 
if (drumno<5) 
{ 
outbyte = 1<<drumno; 
outbyte|=shadow_0OxBD; 
write_to_reg(0xBD, outbyte) ; 
} 
} 


void stop_drum(int drumno) 


{ 
char outbyte; 


if (drumno<5) 
{ 


outbyte = 1<<drumno; 
outbyte “= Oxff; 
outbyte & shadow_0xBD; 
we want to turn off 
write_to_reg(0xBD,outbyte) ; 
} 
} 


write_to_reg(Oxbd,0x20). fm_reset() can 
be used to prepare the chip for program- 
ming and to quiet it down when you're 
finished. 

write_to_patch() sets up a voice on 
the soundboard. If you have a PatchData 
structure called SaxPatch and you wanted 
to set the first voice to it, you would use 
write_to_patch(&SaxPatch,0). play_voice() 
plays a voice. For example, once you’ve 
set up your saxaphone patch as voice 0, 


// bass drum 
// all other drums 
// all other drums 


// bounds checking for safety 


// move bit into proper position 
// or with shadow so we leave other bits intact 


// bounds check 


// move bit into proper place 
// turn into a mask 
// leave all bits on in drum_shadow except one 


you can use play_voice(0,4,2) to play D 
above middle C. stop_voice() stops a 
voice. It will release naturally. To quiet 
your saxaphone use stop_voice(0). 
MAIN.C shows an example of 
FMLA. 


sample_patch is an example of a particu- 


using the functions in 
larly boring instrument. Play with these 
values, and you'll discover that it is quite 
difficult to get a good sound out of an 
adlib. Persevere! It can be done. 
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// Prototypes and structures for frequency modulation code. 


// Jamie Fristrom 
#ifndef FM_H 
#define FM_H 


typedef struct { 


// parameter 1 is the modulator, parameter 2 is the carrier 


unsigned char flags1; 
unsigned char flags2; 
unsigned char ksl_attn1; 
unsigned char ksl_attn2; 
unsigned char att_decl; 
unsigned char att_dec2; 
unsigned char sus_rell; 
unsigned char sus_rel2; 
unsigned char wave_sel1; 
unsigned char wave_sel2; 
unsigned char fdbk_alg; 
} PatchData; 


void write_to_reg(char reg,char value) ; 
// Write to an OPL2 register 


// registers 0x20 to 0x35 
// registers 0x40 to 0x55 
// registers 0x60 to 0x75 
// registers 0x80 to 0x95 
// registers Oxe0 to Oxf 


// registers Oxc0 to Oxc8 


void write_patch(PatchData *pd,int voice_no) ; 


// Set a patch on the OPL2 


void fm_reset(void) ; 
// Reset the OPL2 


void set_frequency(int voice_no,int octave,int note) ; 
// Set a given voice frequency. Used primarily for drums. 


void play_voice(int voice_no,int octave, int note); 


// Play a given note on a given channel. 


void stop_voice(int voice_no); 
// Stop a channel from making noise. 


void init_drums(void) ; 


(Note goes into release mode. ) 


// Initialize drum mode, and set up drums to sound tolerable. 


void play_drum(int drumno) ; 
// Play a drum: 


// 0 = hat, 1 = cymbal, 2 = tom, 3 = snare, 4 = bass 


void stop_drum(int drumno) ; 
// Stop a drum 


tendif 


Where to Go from Here? 

So, now you can make sounds. What 
you're probably wondering now is how 
you can make the sounds cool, how you 
can combine the sounds into a song, and 
how you can play the song in the back- 
ground while the game is running? 
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I can’t go into these details here, but 
Pll give you some hints. A library of 
patches is a good thing to have; the best 
way to make one is to develop a program 
that allows you to make up and tweak the 
variables in a patch, see how they sound, 
and save those patches to disk. 


Combining the sounds is a whole 
different scenario. At my company, we 
use a commercial sequencer that creates 
MIDI files, and I wrote a program that 
reads those MIDI files into the comput- 
er and forces the AdLib soundboard to 
play the song as close as it can to the file 
that it’s reading, using a library of patch- 
es that emulate standard MIDI instru- 
ments. An easier to program but harder 
to use solution would be to make your 
own song files that have information on 
how long you want to play which notes 
and read those files in to your computer 
and tell the AdLib soundboard what you 
have in mind. 

Playing the song in the background 
requires getting friendly with the timer 
chip that interrupts your computer 18 
times a second to tell DOS that it’s time 
to advance the clock an eighteenth of a 
second. Lewis C. Eggebrecht’s Interfac- 
ing to the IBM PC, Second Edition, 
(SAMS, 1991) tells how to change the 
speed of the timer chip, and most pro- 
gramming-under-DOS manuals have 
information on how to write your own 
interrupt that the computer will call 


instead of the timer. 


Jamte Fristrom studied electronic 
music at the University of California at 
San Diego. Upon graduation, he went to 
work for MindCraft Software, working on 
the music code for most of 1ts games. He 1s 
currently the project leader and head pro- 
grammer for Gryphon Masters, as 32-bit 
fantasy role-playing game inspired by Celtic 
mythology. 
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by Alexander 
Antoniades 


On the road from video 


production company 
-— tointeractive enter- 
—__ fainment developer, 


WOU Can travel fo 


some strange places, 
from an old liberty 
Ship in oan Francisco 
fo a trip to the local 


butcher shop. 


Drew Pictures: 
The Making 
of Iron Helix 





f Drew Picture’s game Iron Helix 

had a birthplace, it would be the 

Jeremiah O'Brian, a floating muse- 

um located in the Marina district 

of San Francisco, Calif. It was 
there that the big idea of Drew 

Pictures founders Vincent Carrella 

and Drew Huffman finally clicked. 
It was an idea that had its roots from 
when Carrella and Huffman were work- 
ing at Paracomp. 

Huffman was working as product 
manager for a computer animation pro- 
gram called Film Maker. Carrella was a 
strategic marketing person who did 
hands-on demonstrations on roadshows 
with Huffman. It was during these 
roadshows that Carrella and Huffman 
spent a lot of time together and talked 


about their future plans. Huffman want- 
ed to start his own production company. 

Huffman eventually left Paracomp 
to start Drew Pictures. A year later, 
Carrella came on board. The company’s 
main focus at that time was video pro- 
duction and animation for commercial 
television and a variety of hi-tech 
clients. That all changed when the 
company was asked to work on a mod- 
ule of a large CD-ROM project and 


came upon a great idea. 


The Big Idea 


Drew Huffman’s original concept was 
designing a game around the limita- 
tions of the CD-ROM. By storing the 
main program on the hard drive, the 


designers could use the massive storage 


The main interface screen of Iron Helix was the final result of a balancing act between 
technical and gameplay considerations. 





GAME DEVELOPER ¢ PREMIER 1994 45 


DEVELOPIAG 





potential of the CD-ROM to store 


sound and video the program could 


access as needed. 

One of Huffman’s original ideas 
involved piloting a robot around a three- 
dimensional virtual environment with a 
view through a small window. The chal- 
lenge was to justify the small window 
size. Drew Pictures designers developed 
a storyline where the robot was exploring 
a large ship that was too dangerous for 
humans to explore. This led to an inter- 
face design in which the player is con- 
trolling a robot from a safe vantage 
point, making what the robot sees in the 
view screen just a small part of the over- 
all scenario. 

While Huffman continued working 
in video production, Carrella started 
investigating the Macintosh CD-ROM 
market. They made a favorable business 
plan in which he stated that based on the 
success of CD-ROM games such as 
Spaceship Warlock and Reactor, the 
Macintosh CD-ROM market was 
potentially profitable. However, Huff- 
man and Carrella still weren't sure, 
because of technical limitations, develop- 
ing a CD-ROM was the right thing to 
do. 

There were two main objectives 
Huffman wanted to accomplish in his 
game: 
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Figure 1. The Original Jeremiah O'Brian 


AON 


- To get smooth playability off a CD- 
ROM drive 

- To suspend disbelief that someone 
was playing a game. 

The CD load times were very frus- 
trating, but they now knew they could 
overcome that limitation. The release of 
the Quicktime 1.0 animation engine for 
the Macintosh promised consistent play- 
back of video animation and finally con- 


The Jeremiah O’Brian Spaceship 


HEL IM 





vinced the pair that the game was tech- 
nically possible. 

A visit to the Jeremiah O'Brian, 
shown in Figure 1, finally made all the 
pieces fit. The atmosphere on that his- 
toric ship gave them the feeling of what 
they were trying to convey in the game. 
They even thought of doing a documen- 
tary about the Jeremiah O’Brian. But in 
the end, they decided to go into the 
game business instead of testing the 
treacherous waters of educational multi- 
media. They did name the game’s main 
spaceship after the ship in homage. 


Inspiration and Perspiration 
They decided to use Macromind Direc- 
tor from Macromind as the authoring 
tool to create the game. J.A. Nelson, an 
old associate of Huffman, joined the 
team as its Director expert. Rich Cohen, 
a technical director at Industrial Light 
and Magic, also joined the team as art 
director. 

For the next year and a half, every- 
one worked out of Huffman’s apart- 
ment, trying to build a game and a game 
company. Their experience showed 
them how important it is to understand 
business and not just game development 
to become a successful company. To 
learn what they were getting into, they 








talked to professional game developers 
and distributors. 

It was about three months into 
development that they realized Quick- 
time 1.0 wasn’t going to cut it. It could 
not maintain the consistent frame rate 
the designers wanted. What they ended 
up using in the final game was an anima- 
tion engine called PACo from The 
While 


Quicktime isn’t used in the final version 


Company of Science and Art. 


of Iron Helix, the designers insist that 
the game couldn’t have been made with- 
out it. 

Instead of writing the story first and 
then developing the game, they devel- 
oped both in conjunction, allowing 
themselves to make adjustments as they 
ran into technical difficulties. One of 
their major complaints about CD-ROM 
games was the character interaction. 
One of their pet peeves about CD- 
ROM games is that the CD-ROM is 
too slow to have live video interactions. 
To get around this limitation, all the 
characters in the game are dead—the 
player views video clues they have left 
behind. 

As they worked more on the game, 
eventually the whole plot was fleshed 
out. The story revolves around a run- 
away spaceship containing a biological 
weapon and a doomsday device. The 
player controls a robot probe that is 
piloted around on a spaceship. All the 


crew is dead, so the player looks around 


The Darwin Probe 





Figure 2. Meat or Microbe? You Make the Call! 
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the ship for pieces of the crew’s DNA, 
which is used to gain access to more of 
the ship. However, every time certain 
parts of the ship are accessed, the 
Defender robot patrolling the ship will 
become aware of the player’s presence. 
The player accesses video clues left 
behind by the former crew, which show 
how to destroy the Defender robot and 
the dangerous spaceship. 


Iron Helix 
The way the story was written, most of 
the animation takes place inside two 
windows on the screen. The primary 
window contains the robot probe’s 
remote camera view, and the other con- 
tains the interface where the player views 
videos and the DNA scans, among other 
things. 

The images in the primary display 
window are all computer-generated 


The tools 


used to make these were Macromedia’s 


three-dimensional images. 


Swivel 3-D Professional and Macro- 
model. Every segment was animated 
individually in development and 1s pulled 
off the CD-ROM in real-time when the 
probe is moved in the game. The origi- 
nal plan called for the probe to be able to 
tilt and pan in its movement, but it was 
too much work, and the developers felt 
that it didn’t enhance gameplay. In the 
end, the probe would be able to turn at 
90° angles and move at fixed increments 
with transitional animation linking every 


Move. 


Thy. rina. — 
Lh ly pt bil 


Of course, in the instances where 
the Defender kills the probe, there must 
be additional animation sequences. The 
developers calculated all the places where 
the player could possibly die and decided 
to only include the most probable sce- 
In the end, out of 600 locations 
where the player could die, they made 


narios. 


250 unique death sequences and a gener- 
ic death scene for the rest. 

The secondary animation window 
in the main interface screen displayed, 
among other things, the video images of 
the dead crew. For those video pictures, 
they used mainly the Drew Pictures staff 
They filmed the 
sequences in the office and later changed 


the backgrounds with Adobe Premiere. 


and friends as actors. 


The Creative Process 
In the part of the game where the player 
has to find the dead crew’s DNA, a close 
up scan appears in the same window as 
the videos. The original idea was that 
the player would manually match the 
DNA of the dead crew members. Car- 
rella spent two months studying DNA 
matching. He got out all his old biology 
texts and even spoke to an FBI lab. In 
the end, he found that real DNA match- 
ing was too hard to simulate, so that any 
simulation would be so simplified it 
wouldn’t have any educational aspect, 
which was one of the main reasons he 
wanted to do it. 

Making the actual image for the 
DNA samples, shown in Figure 2, was 
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another story. Carrella was fond of elec- 


tron micrographs and wondered how he 
could get the same effect from pho- 
tographing other things. He pho- 
tographed hunks of meat and chicken 
innards and used a program called Tex- 
tureSynth to make the background, 
mixed them in Adobe Photoshop, and 
threw in other touches to make the shots 
look authentic. 

Early in the development process, 
the designers started looking for a dis- 
tributor because they knew the distribu- 
tor would be crucial to the game’s suc- 
cess. They sent Gilman Louie, chair- 
man of Spectrum Holobyte, a descrip- 
tion of what they were working on. 
Louie was interested, but he could not 
negotiate with them at that time. Five 
months later, after they had talked to 
Electronic Arts, Sony, Broderbund, and 
Educorp, Drew Pictures negotiated the 
distribution contract with Spectrum 
Holobyte. 

Spectrum Holobyte helped the 
team jump a big hurdle in its develop- 
ment process by taking one of the alpha 
versions to a focus group. It was in that 
focus group that many of the playability 
features were corrected. In the original 
game, the robot probe had to manually 
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open a door, which wasn’t very popular 
with the playtesters. As a result of that 
meeting, the designers added more 
DNA , more levels of difficulty, and the 
ability to momentarily jam the Defender. 
The focus group consisted of hard-core 
gamers as well as novices to address the 
games impact on a larger audience. 


Money and Markets 
Oddly enough, the Japanese version of 
Iron Helix was available before the Eng- 
lish version. This was because Spectrum 
Holobyte was more demanding than 
Drew’s Japanese Distributor. The whole 
game remained in English for the Japan- 
ese version, as did the French and Ger- 
man versions, with only subtitles for the 
specific foreign language. The foreign 
version was distributed as a test only. 
Currently, the foreign CD market is too 
small, and foreign sales account for less 
than 10% of Drew Pictures’s total profit. 
After the team successfully com- 
pleted the Macintosh version of Iron 
Helix, it started work on a PC version. 
The designers chose to do it for Win- 
dows instead of DOS, so they wouldn't 
run into driver problems with the DOS 
CD-ROM drivers. One problem they 


did run into, however, was that the per- 





formance of the Windows version of the 
Director player wasn’t good enough to 
use for the game. It was at this point 
that Bill Zettler, their director of engi- 
neering, programmed his own engine in 
C. The designers will continue using 
Director for development and are work- 
ing with Macromedia on the speed issue. 

Despite problems with the environ- 
ment, the Windows version of Iron Helix 
outsold the Macintosh version in its first 
week. “Each version is a refinement,” 
says Carrella, “The PC version is a better 
game than the Mac version.” Although, 
he stresses that it’s just the gameplay 
that’s better, not the experience. In his 
opinion, the PC game market is very 
finicky; games like Hell Cab and the 
Journeyman Project will do better on the 
Macintosh. “There’s less room for error 
on the PC,” points out Carrella. 


The Future of Iron Helix 

The next version of Iron Helix will be 
for the Sega CD. The designers were 
thinking of doing a 3DO version, but 
Sega’s large installed base changed their 
minds. If they do make a 3DO version, 
they want to write a new version of the 
game instead of porting the Macintosh 
version, and the Sega version will be 
redesigned to be faster. They are not 
planning to develop a CD-I version of 
Iron Helix, but the Atari Jaguar looks 
like a promising platform. They do, 
however, expect 3DO to become a dom- 
inant player in the future. 

Since the original success of [ron 
Helix, Drew Pictures has been working 
on new projects and looking in new 
directions. The designers want to make 
games that combine cinema styles with 
arcade-level play. Drew Pictures sees 
itself primarily as an interactive enter- 
tainment company that makes games 
instead of a game company. As Huff- 
man put it, “One thing I can confidently 
say is that Drew Pictures will never make 
a shoot em up game.” Hf 


Alexander Antontades 1s the assoctate 
editor of Game Developer and assistant 


editor on OS/2 Magazine. 


BOOK 


REVUES 





by Thomas Murphy 


If You re interested in 
gaming, but haven't 
made the investment 
in technology, start 
WITH a fel DOOKS on 
the subject. These 
late-night page- 
[urners will spark 
your interest and fire 


your enthustasm. 


Let’s Go 


Fiy a Kite 


f I guess right, most of you aren’t cur- 

rently programming games for a living. 

You picked up this magazine to learn 

the tricks employed by the best game 

developers, and you secretly dream of 

making it big with the next game of 

the month. Even if you are living by 

games, you are probably always inter- 
ested in learning new tricks and techniques 
to make your games faster. 

Enter the world of programming 
books. Usually, these tomes are simple 
rehashes of the compiler manuals written 
with a few new, trite examples. Or, they are 
filled with technical descriptions of lan- 
guages and are great for reference if you are 
a compiler builder but not as useful for get- 
ting a sprite to dance like M.C. Hammer 
across the screen. There are a few good 
software development books out there, 
though, and some have found lasting space 


on my bookshelf. 


Taking Flight 

A recent title is Flights of Fantasy by 
Christopher Lampton. This book is filled 
with useful information and nice hunks of 
code that will move any beginner down the 
road to successful game programming and 
serve as a good quick place for the seasoned 
veteran to find the fundamentals. All code 
in the book is written in either C++ or 
assembly language, and the end product of 
the book is a basic flight simulator. 

Probably the largest flaw of this text is 
that it is centered around mode 13h, which 
is a resolution of 320-by-200 with 256 col- 
ors. This is nice for getting started, but will 
never do for serious realism. Still you can 
make use of the concepts, start here and 
simply change modes and bounds for arrays 
loop controls to move up to a higher resolu- 


tion. Mainly, you will get a good quick look 
at how Os and 1s turn into colors on your 
screen. If you understand this, move on. 

After learning how to set the video 
mode and build your palette, you dive into 
the world of bitmaps. Lampton has good 
quick explanations of .PCX formats and 
data compression. You then learn how to 
animate bitmap sprites and add in interac- 
tion with the outside world. 

After you understand the basics of 
moving flat objects, the next task is learning 
three dimensions. Flights of Fantasy explains 
the basics of what is happening without 
bogging you down in the numeric details. 
You learn all about rotation and translation 
as well as the standards of clipping and fill- 
ing. ‘The segments are all easily understood 
and written with the help of John Dlugosz 
and Mark Betz. 

As a sidelight, if you are really looking 
for information, tips, and tricks for game 
and graphic programming, you should 
spend time on CompuServe in the Game 
Developer’s Forum (GO GAMERS). 
There, you can readily find Betz, Lampton, 
and several other useful and friendly indi- 
viduals. 

After lots of instruction on graphics, 
there is a brief chapter explaining the funda- 
mentals of working with the SoundBlaster. 
This is really a quick touch, explaining how 
to turn the card on and send it simple sets of 
tone settings to create sounds. The book 
comes with a set of device driver files for 
running the general functions of the board. 

The finishing touch of the book is 
putting everything together by building a 
simple flight simulator. This way, you get 
to go beyond how to do the job to the 
dynamics of what should really happen and 
how the game relates to the real world. 
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This book doesn’t have anything magi- 


cal, it is just a nice compilation of good code 


and basic explanations. It is also the only 
book that really looks at things in a game- 
oriented fashion. All the code is on disk 


and, at $34.95, the book is reasonably 
priced. 


Other Books on My Shelf 

Once you know the basics, you will be ready 
to move on to more advanced courses. 
These come in books not really aimed at 
game development but definitely filled with 
great information. Most of that information 
will be on the topic of graphics. New tricks 
are always being invented, and the continual 
improvement in processor performance 
makes realism much more affordable. 

A great book for Borland C++ users is 
Advanced Graphics on VGA and XGA Cards 
Using Borland C++ by Ian Angell and Dim- 
itrios T'soubelis. They are professors who 
have been teaching graphics at a university 
in London for the past 15 years and wanted 
to bring their knowledge to people with 
standard machines. As they well state, most 
graphics books are generally filled with 
algorithms but not code, and they are geared 
toward users with workstation muscle. 

While this book does not aim itself at 
game development, it is filled with more 
detailed information, and the educational 
background of the authors shows through 
with discussions of data structures and the 
strengths and weaknesses of various algo- 
rithms. This is a more frightening book for 
the math phobic. On the other hand, you 
will learn about various shading, transparen- 
cy, and raytracing methods. All the material 
is designed to produce great images, it just 
doesn’t tie it all together into an action 
packed game. 

A much-loved graphics series is Graph- 
ics Gems volumes one, two, and three, edited 
by Andrew Glassner. These are filled with 
great tidbits of information explained as 
algorithms and generally supplemented with 
C source code. The contributions come 
mostly from academic research with a smat- 
tering from industrial think tanks. The 
great thing about these books is their up-to- 
date nature. Unless you having been reading 
the ACM’s Transactions on Graphics, you are 
not really keeping up with the latest tricks. 
Graphics Gems will help fill in the gaps. The 
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explanations are short, to the point, and very 
numeric. 

My personal favorite reference is Com- 
puter Graphics Principles and Practice by 
James Foley, Andries Dam, Steven Feiner, 
and John Hughes. This in-depth text covers 
the basics to the esoteric. It is geared more 
toward high-end systems with discussions of 
display processors and parallel processing. 
This does not affect the basic material, 
though, and you will find everything includ- 
ing in-depth discussions of radiosity tech- 
niques and volume rendering. 

While I love high-end rendering tech- 
niques, you really don’t have much time to 
make use of them in a game. It is true that 
processors can do much more than just a few 
years ago, but once you add opponent intel- 
ligence, a sound track, and try to start sling- 
ing polygons around let alone shade them, 
you'll begin a rapid slide into slow land. ‘The 
trick is to learn how to fake it. 

This brings me to the last book you'll 
want to have in your library—Bitmapped 
Graphics Programming in C++ by Marv Luse. 
This book gives you good coverage of vari- 
ous image formats, printing, pixel mapping, 
compression, and dithering techniques. 
Combine the included routines for working 
with bitmaps with the graphics routines that 
stretch and texturize plain polygons and you 
just may have something. If you aren’t 
interested in three-dimensional graphics, 
you will still be able to put this information 
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to use in building realistic backgrounds for 
your sprites to run around on. 


Your Bookshelf 


All these books provide useful information. 
If you are just getting started with game pro- 
gramming and are moving into a new area, 
you will probably find just enough to get you 
going in Flights of Fantasy. It is unique in 
giving you not just graphics, but sound and 
user interaction too. Once you get beyond 
this level, you should be well on your way 
and will probably be able to pick-up the rest 
of what you need through trial and error and 
asking the right questions. 

For those of you who need more 
graphics meat, Angell and Tsoubelis cover 
much of the same material but tell you how 
to do what Lampton only describes as a 
future task. Computer Graphics Principles and 
Practice is the definitive graphics reference 
but may be a little too much. | love graphics 
and math, so it is right up my alley, but if 
you are more interested in simply learning a 
few trick algorithms, Graphics Gems is proba- 
bly better for you. 

At any rate, there is a lot more to game 
programming than graphics and user inter- 
action. First, you need a story and lots of 
logic, a graphics artist, a musically inclined 
person, and lots of time. i 
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by Stephen 
D. Wiison 


rithms, artificial intel- 
ligence, and a C++ 
framework, you can 
prgram a spaceship 
that learns the best 
path for itself as it 
hurtles through 
space—a facinating 


addition to any game. 





n 1989, the Galileo space probe 
left Earth on a mission to the plan- 
et Jupiter. When Galileo arrives, 
sometime in 1995, it will launch a 
probe into Jupiter to explore the 
depths of the gas giant. Planning a 
mission of this magnitude is a truly 
colossal effort involving many 
mathematicians, physicists, and com- 
puters. I recently applied the technolo- 
gy known as genetic algorithms to part 
of this task. My results seem to indicate 
that genetic algorithms have potential as 
part of the space program. 


Background 

The path Galileo is taking on its way to 
Jupiter boggles the mind. During its 
voyage, it flew to Venus, back to Earth, 
and out from Earth in a long elliptical 
orbit that will lead it back to Earth. It 
shot past Earth and is now on its way to 
Jupiter, flying at a speed of approxi- 
mately 40,000 miles per hour. Why this 
complicated, seemingly redundant path? 
Because it is the shortest route. 

Now wait a minute, you say. I 
learned in school that the shortest path 
between two points is a straight line. 
That lesson would be true if gravity 
didn’t affect our spaceship at all, but it 
does. If we point our ship where Jupiter 
is and send it off, our probe would never 
reach its destination. The gravitational 
forces from the sun and other planets in 
our solar system would change the 
course of the ship drastically. 

The Starflight Handbook discusses 
the magnitude of these gravitational 
forces. Even mundane spheres such as 
the Earth and its moon possess extraor- 
dinary energy of motion. Finding ways 


to extract even a microscopic fraction of 
that energy and convert it to propulsive 
ends had been a favorite theme of inves- 
tigators for some time. This is ironic 
because gravity is an incredibly weak 
force, about 40 orders of magnitude 
weaker that electrostatic force between 
two particles. But when mass gathers 
together in astronomical bodies, its col- 
lective attractive force can be staggering, 
and it permits the fantastic storage of 
energy (even by starship standards!) in 
the orbital motion of celestial bodies. 

The people who figured out 
Galileo’s path knew a lot about physics. 
They knew that space is curved where 
large gravitational fields exist. They 
took advantage of this knowledge, and, 
instead of fighting the gravitational 
forces, they used them to their advan- 
tage. Like a skateboarder in a half pipe, 
the spaceship slides through curved 
space using the gravity wells to change 
its direction and speed. 

Understanding these forces, which 
required great minds like Sir Isaac New- 
ton, is one of the tremendous feats of 
modern science. The challenge I put to 
the genetic algorithm was formidable. 
Could the genetic algorithm create, in 
just a few short hours of evolution, a 
route through a system of planets that 
not only reached its destination, but 
reached it in an efficient manner? 

] will look at the process for solving 
a particular task using a genetic algo- 
rithm, incorporating six steps that are 
generic to any genetic algorithm prob- 
lem. Each step will be examined in 
terms of using a genetic algorithm to 
plan a route for our space probe. The six 
steps include: 
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¢ Defining and analyzing the task 
* Creating the simulation model 
¢ Defining the genome 

¢ Defining the fitness function 


f You are trying fa 
optimize a strate- 
gu with a genetic 
algorithm, create 
a simulation of the 


environment first. 





* Integration 
* Running the simulation. 


The Task 

Defining the task is the first step in any 
problem-solving situation. Genetic 
algorithms are no exception. Here, we 
will decide exactly what we are trying to 
solve in general terms. | wanted the task 
that I assigned to the genetic algorithm 
to be of similar complexity to the Galileo 
mission. 

At first, I wanted to recreate the 
Galileo mission, but had trouble finding 
enough data on the probe and alignment 
of the planets. I decided to create my 
own fictional space probe and put it into 
a fictional system. My system has seven 
bodies, plus the probe. All seven bodies 
would affect each other as well as the 
probe gravitationally. I started the probe 
on one side of the system and had it fly 
to a planet that was on the other side of 
the system. 


The Simulation 

The next task in solving our problem is 
building a simulator. With genetic algo- 
rithm problems, you usually have to 
build a simulator of some kind. Some- 


- Figure 1. Inheritance Tree for Vector Class Library 
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times this simulator can be as basic as a 
simple function you want to optimize. 
The purpose is to create some mecha- 
nism to discern the difference between a 
good and bad answer. 

If you are trying to optimize a busi- 
ness strategy with a genetic algorithm, 
you need to create a simulation of the 
business environment in which your 
company competes. If you want to gen- 
erate neural networks, you need to write 
a neural network simulator first. In our 
case, we had to build a Newtonian 
physics simulator. 

I built a C++ class library called 
Vector. It lets programmers create bod- 
les in a system and simulate their move- 
ments. It also allows for the creation of 
spaceships and the control of their 
engines. Figure 1 shows a diagram of 
Vector’s class structure. | used Vector to 
create a randomly generated system of 
seven planets. 

Each planet had a random mass 
and initial velocity. We then picked one 
of these planets to be the target of the 
mission and placed the probe at the 
opposite side of the system. I created a 
graphical display of the system so | could 
see the motion of the planets and the 








spaceship. I even hooked up the space- 
ship to the mouse and tried to fly the 
mission myself by hand. It was pretty 
tough. Approximately one in three 
times | could make it to the target, but I 
_used almost all the fuel and took quite 


some time to get there. 


Defining the Genome 

The second step in solving a problem 
using a genetic algorithm is to define the 
genome for the individuals. In our case, 
we want the genome to represent the 
probe’s actions. I chose to represent this 
genetic structure in terms of course cor- 
rections. The probe thrusts with a given 
force in a certain direction. It then waits 
some amount of time and thrusts again 
to change its course and speed. This 
step is repeated several times. In our 
case, each course correction has three 
independent variables that correspond to 
three genes in the genome. 

The first will be the number of time 
steps after the last burn that this burn 
will occur, or, in the case of the first 
burn, how long to wait to activate the 
engines. ‘The second gene in this group- 
ing of three will be the horizontal com- 
ponent of the thrust vector. The last of 
the three will be the vertical component 
of the thrust vector. I arbitrarily picked 
30 as the number of course corrections, 
which means that the genome will have 
90 genes (three for each course correc- 
tion times 30). Figure 2 shows a visual 
representation of the genome. 

I decided that both components of 
the force vector will have between nega- 
tive 50 and positive 50 units of force 
they can apply. Again, in my simulation, 
these numbers were arbitrary. In a real 
problem, the spacecraft’s limitations 
would dictate these numbers. I also 
arbitrarily decided that there would be 0 
and 100 time units between course cor- 


rections. 


The Fitness Function 

The next step in the process was to 
quantify the difference between a good 
and bad answer. In genetic algorithms, 
this step is called the fitness (or objec- 
tive) function. We create a mathemati- 


cal function that assigns a numerical 


Figure 2. The Genome of an Individual 








Equation 1. The Fitness Function 





value to any possible solution. A good 


answer has a high fitness. A bad answer 
has a low fitness. This fitness value will 
be used later in the basic heuristic that 
powers evolution’s survival of the fittest. 

For this problem, I chose three cri- 
teria to optimize: distance from target, 
amount of fuel used, and length of time 
to reach target. Other criteria might be 
used. Also, some might argue that 
amount of fuel used is irrelevant as long 
as the probe doesn’t use more that it is 
allotted. In any case, I chose the three 
I’ve listed. 

Obviously, the most important part 
of the equation is whether the probe 
reaches its destination. However, these 


other considerations are also important. 
For example, if the probe reaches its des- 
tination but takes 500 years, it doesn’t do 
us much good. The fitness function I 
used is shown in Equation 1. 

Remember that a high fitness indi- 
cates a good answer. Here, we square 
the distance from the target to punish 
severely individual answers that do not 
reach the target, which means that a 
probe that gets within 10 kilometers of 
the target will have a penalty of 100 sub- 
tracted from its fitness. A probe that 
only gets within 100 kilometers of the 
target will have 10,000 subtracted. 

Next, we look at the fuel remaining 


in the probe. We add points to the 


Figure 3. The MicroGA Class Structure | 
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Listing 1. C++ Member Function MakeGenes() 





Listing 2. The CalcObjectivel) Function 


probe’s fitness score if any fuel remains. 


Lastly, we penalize the probe for the 
amount of time it took to reach its tar- 
get. Thus, if a probe came within 25 km 
of the target, had 15 kg of fuel left, and 
took 300 days to get there, it would have 
a fitness of negative 915. Some genetic 
algorithm systems have problems with 
negative fitness values, but the system we 
used had no such problem. 

Using calculus, you can determine 
quickly the best path for a ship flying in 
a system with only one other body. You 
can even find, with considerably more 
difficulty, the best path for a ship when 
two other bodies exist. With more than 
two bodies, simple, calculus-based meth- 
ods leave you out in the cold. In our 
problem, we looked at a system with 
seven other bodies, which means that no 
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closed-form solution to a problem of this 
complexity exists. These problems are 
attacked using a variety of complex 
numerical solutions. 


Integration 

The final step is to make the simulation 
code and genetic algorithms work 
together. For this step, we will use 
MicroGA, which is a C++ framework 
that uses object-oriented concepts such 
as inheritance to make it easy to use and 
customize. It has classes such as TPopu- 
lation, TIndividual, and TGene. An indi- 
vidual is a possible solution to a given 
problem. Each individual has a set of 
genes that represents the values of the 
independent variables in the problem. A 
population is a group of possible solu- 
tions. See Figure 3 for the class structure 


SITES HET 





of MicroGA. 

When you solve a problem using 
MicroGA, you 
TIndividual. This subclass is where you 


must subclass 
define the problem you plan to solve. In 
this subclass, we must write two impor- 
tant functions. The first is called 
MakeGenes(). This subclass is where we 
define in code what the genome will 
look like. Listing 1 shows a C++ code 
fragment that displays this member 
function. 

Each gene in our genetic algorithms 
represents one independent variable in 
our problem. NumberGenes is set to be 90 
because we have 90 independent vari- 
ables. Thus, we go through this loop 30 
times. The three genes created inside 
the loop are the three variables required 
for a course correction. The first is the 
amount of time that elapses between the 
last course correction and the current 
one. The second one is the X component 
of the thrust vector. The third one is 
the Y component of the thrust vector. 
The numbers passed as parameters to 
the TGene constructor are the maximum 
and minimum values that that variable 
can take. The time among course correc- 
tions is between one and 100 time steps. 
Each component of the thrust vector 
must be between negative 50 and posi- 
tive 50 units of force. 

The other function we must write 
when using MicroGA is called CalcOb- 
jective(), which is where we define the 
fitness function. Each individual is eval- 
uated against an objective function. If it 
does well compared to other individuals 
in the population, then it is likely to sur- 
vive and mate to produce offspring. If 
the individual scores low, then it most 
likely will die without producing off- 
spring, as shown in Listing 2. 

In this function, we spool up all the 
gene values in the individual into an 
array. We then pass away these values, 
which represent instructions for the 
spaceship, to a function called DoSimula- 
tion, shown in Listing 3. DoSimulation 
returns a value that represents how well 
that path worked. The value is then 
stored in the individual. 

I'll show you step by step what hap- 


pens. First, we make a copy of the sys- 


Listing 3. The DoSimulation() Function 


tem in its initial state. We then start 
into a loop. This loop continues as long 
as two criteria are met: first, that the 
spaceship exists (which means that it 
hasn't crashed into any planets along its 
path or reached its destination); second, 
that less than 500 time steps have 
elapsed. Several things happen inside 
the loop. The first thing we do is tell the 
system to DoNextTimeStep(), which means 
that the system will calculate the gravita- 
tional forces between all the bodies in 
the system and move them. 

We also keep track of how many 
time steps have elapsed in the variable 
called counter. Next, we check to see if 
it is time for the next course correction. 
If it is, we tell the ship to thrust. We 
pass along the values of two of the indi- 
vidual’s genes to the thrust function. 
When the simulation is complete, mean- 
ing the ship has reached its target, 
crashed, or run out of time, we calculate 
the fitness for this probe using the func- 
tion we defined before. 

Later, the population object will 


decide whether this individual is fit to 
mate. Note that the genetic algorithm 
has no information on how the problem 
works or even what the problem is. It 
simply passes in values and works solely 
off how good the answer is. After the 
ship is given its instructions, it flies 
blind. It has no sensors and gets no 


feedback. 


Running the Simulation 
The evolution takes place in the next 
step. We will let MicroGA take care of 
most of the work. All we have to do it 
set up some parameters. These parame- 
ters are generic to most genetic algo- 
rithms. The first and most important 
one is the number of individuals in the 
population at any one time. For this 
problem, I chose a relatively small popu- 
lation of 25 individuals. I would have 
used more, but decided to try a small 
population and increase it if it became 
necessary. 

The next parameter is the number 
of generations for which we want to run 


Mith this simula- 


tion, our new 
Spaceship has no 
(rouble navigating 
the dangers of an 


ateroid Del. 


the simulation. [| initially chose 50. I 





found that a good heuristic is to let the 
population evolve for a number of gener- 
ations equal to two times the number of 
individuals. The population usually 
doesn’t get much better after that long. 
The last parameter is the mutation rate, 
which is the percentage change that any 
given bit in an individual’s genome will 
mutate. For this problem, I used 1%, a 
fairly common default. 

Now, we set the simulation to 
work. After about five generations, 
some of the probes in the population 
were making it to the target. Over the 
next 15 generations, the probes in the 
population evolved to be more efficient 
in fuel usage and the amount of time it 
took to get there. By 20 generations, we 
had achieved what appeared to be a 
near-optimal answer. | experimented 
with a few different settings for the para- 
meters, but found they all converged to 
similar answers. 


Results 
Now that we are done, you might ask, 
“Did it work?” The answer is it worked 


great. Our new spaceship has no trouble 
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navigating the dangers of the asteroid 
belt. Not only does it reach the target 
planet, but it does it in a short amount of 
time and uses almost no fuel. In a mat- 
ter of five simulated generations, the 
ship reaches the target. After 20, it has 
locked in the near-optimal path. Think 
about it. We tried only 500 solutions 
(25 individuals times 20 generations) out 
of all possible paths. The total number 
of variations in the genome we laid out 
was so large I couldn’t calculate it on my 
pocket calculator (the actual number is 
100 to the 90th power). 

The program we wrote can run 
about 10 generations per hour on my 
Macintosh IIfx computer. In the two 
hours of evolution that the program ran, 
it discovered advance techniques in 
spaceship navigation. It learned to use a 
gravity-whip technique whereby it passes 
close to one of the other bodies and 
shoots away, taking some energy from 
the body and increasing its own speed. It 
learned to use the gravity wells of nearby 
bodies to change its speed and direction 
so it wouldn’t have to expend fuel. In 
one simulation, the ship flew between a 
large body and a smaller one trapped in 
orbit around it. It used this maneuver to 


make a drastic course change and inter- 


cept the target body. 


Final Notes 

Although these results show much of the 
power of genetic algorithms, this type of 
answer is brittle. It solves only one route. 
An ideal solution would be more gener- 
al. For example, wouldn't it be better to 
evolve a general-purpose algorithm for 
piloting a space probe rather that just a 
single route? People have started to do 
applicable research. A new technique 
called genetic programming uses genetic 
algorithms to evolve algorithms, or full- 
fledged computer programs, to accom- 
plish a given task. 

This problem seems like a natural 
for genetic programming. Another pos- 
sible solution would be a hybrid solution 
using a combination of genetic algo- 
rithms and artificial neural networks. 
Genetic algorithms and artificial neural 
networks have been used successfully 
together on several occasions. Research 
has been done using genetic algorithms 
to train artificial neural networks or to 
design the configuration of the neurons 
in different layers. Either of these solu- 
tions might serve to evolve a self-suffi- 
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cient probe pilot. In the meantime, | 
think in this case, genetic algorithms will 
prove to be a powerful tool for this type 
of problem. Mf 


Steve Wilson 1s a partner in Emergent 
Behavior, a software company based in Palo 
Alto, Calif., which specializes in object-ort- 
ented software, including the Mucrogenetic 


algorithms framework. 


SUGGESTED RERDING 





(noun) 1. One who keeps the 
environment green. 2. A series of clip- 
and-save tips for keeping your business 


OHEEN-REEPER 


and home environments green. 


. oe 
How to help 
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Foon the boardroom to the mail- 
room to the lunchroom to the wash- 
room, there may be more ways than 
you think to help your company be- 
come environmentally responsible: 

e Use recycled office paper 


e Develop in-house recycling 
programs 


e Use reduced or recycled product 
packaging 


e Use glassine or open window 
envelopes 


e Purchase compact fluorescent 
light bulbs 


e Buy company coffee mugs 


e Send weekly departmental 
newsletters instead of daily memos 


B.: how can you help your com- 
pany make these changes? Where 


can you find energy-saving, recyc- 
lable, and recycled materials? How 
can your company recycle its own 
waste? And how can you do it at little 
or no expense—or even save money? 


Ty some of the suggestions in 
Keeping Your Company Green, written 
by Stefan Bechtel and the editors at 
Rodale Press. This how-to guidebook 
is packed with “simple, doable steps 
your company can take to help keep 
itself—and the world—green.” The 
book also includes a handy Directory 
of Green Products and Services. For 
further information, contact Rodale 
Press at 1-800-441-7761. 


Permission granted by Rodale Press Inc. 


The Green-Keeper series is sponsored by 
the Miller Freeman Inc. Green Project. 





Liquid Image Corporation Presents: 


The Toughest Thing to Hit VR: 


The MRG 2 is aimed at the VR entertainment market, where 
color, resolution, durability and reliability are of utmost im- 
portance. Yes, there are other products on the market that are 
lighter, but Liquid Image Corporation sure hopes you don’t 
drop them or bang them about. The MRG 2 withstands con- 
stant drops, bangs and other abuse that would demolish other 
HMDs and has never had a failure in the field due to regular 
use. 


The MRG 2 has received praise from many different com- 
panies in the entertainment market and not just for its robust 
design. Liquid Image Corporation has become a leader in cus- 
tomer service providing our clients with the service and prod- 
uct they require. With three week delivery* door to door and 
many options to customize the MRG2 for your particular ap- 
plication, it’s easy to see why the MRG2 has caught on so 
strong. Just some of the options include custom painting and 
decals, discreet internal mounting of your tracker, detachable 
or secure connectors, spares policies, and overseas PAL op- 
tion. 


As if all this wasn’t enough Liquid Image Corporation goes 
yet one step further. Although already an excellent value for 
the regular $6,500.00 U.S. price tag, we offer substantial edu- 
cational and volume discounts. Although some will tell you 
that an HMD isn’t an HMD unless it’s stereo, experts agree 
that for vehicular and flight simulation, and entertainment 
it’s just not required. If you have a desktop application, please 
don't call us; many companies make delicate stereographic 
headsets that will look great on your desk. But if you have a 
heavy duty, high volume application that requires the best 
picture available for a reasonable price tag, and you only want 
to buy one graphics engine, then we’re the company to call. 


saat 





Above Right 
And Lett - 
Unmodified 
MRG2 
Undergoing 
Stress Tests. 


Display: 


Optics: 

Field of View: 
Video Signals: 
Audio: 

Position Sensing: 
Power Supply: 
Fit Adjustment: 


Cable Length: 


Controller Box: 


Options: 


The MRG 2 





Full color TFT-LCD display (16.7 Million colors); 
Pixel count: 240 x 720 (VxH): Dot pitch: 
0.365mm x 0.158mm (VxH): Pixel size arrange- 
ment: RGB Delta: Response time: 80 msec; Con- 
trast ratio: 30:1; Display dots: 172,800 


Clear single lens system 
Nominal 84 degrees 

NTSC Composite/analog RGB 
sony digital headphones 


Accommodates the Ascension Bird and 
Polhemus Fastrak, discreet internal mounting 
available 


120/230 volt AC to 12 volt DC max. Battery pow- 
ered option available fourth quarter 1993. 


Self-adjusting; 5 second don/doff time (maxi- 
mizes throughput) 


3 meters (approx. 10 feet) standard with option 
of up to 6 meters (approx. 20 feet) 


Allows for composite or analog RGB signal; Al- 
lows for video pass-through so that an external 
monitor can be hooked up for external viewing 


Custom painting and decals; Microphone and 
Trackers can be purchased with unit; New holo- 
graphic diffuser now available; Specific client de- 
Sign requirements accommodated easily on 
larger orders. 





Liquid Image Corporation 
659 Century Street, Winnipeg, MB, Canada, R3H OL9 
(204) 772-0137 Fax (204) 772-0239 


*Delivery time may exceed 3 weeks on very large orders 





, Call now to order: 
:  1-800-1,1,1-8826 
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